Wow. So you've been thinking, grigri. I love these brainstorms that we arrive at when we really put our mind to it.

My only concern is what you've already touched on: Explorer replacements are slow(er). I've abandoned everyone I've tried for this simple reason. Making this app skinnable would almost certainly make it slower. (Please correct me if I'm wrong, grigri. I'm not a fraction of the developer that you are). Reading interpreted code (vs. compiled) would slow it down as well, I'd think. Meaning, reading a bunch of XML files could really slow it down...

How will the skinning engine work? Specifically, if a skin isn't supplied, will anything be displayed? That way if one only wants to skin specific aspects of it, they can and possibly limit the overhead.

I really like your thoughts about keeping it object-based and the "adding a view file enables that view, deleting it removes it - simple" approach. That's a very solid stand you're taking. That would make things a lot easier I would think.

Another application of this code could be the desktop. One could truly customize the right-click menu to their heart's content that way

I've done coding in VB and C#, but have little time to assist. Would defintely be a alpha/beta tester, though.

I didn't mean it reads the XML files each time it opens a window - obviously it keeps the loaded ones in memory, as an IMDB. Once loaded, XML queries are fast, perhaps not as fast as a relational database, but much more flexible.
Of course we could just use a normal DB and send SQL queries, that'd be faster, but is it worth it?

As for skins, imagine each "skin" like a css file and accompanying images. If you don't want images, the css file just sets colours, borders, .... The default skin would just have a css, no images, so no overhead.

one question and one cheer

what os is this on. im guessing it's win98.

and the cheer. this is what i've been looking for for a long.

I like what you're saying for XML. Keeping it in a flat file makes it very easy to customize. It would be nice to be able to have a tool to export existing registry information into an XML file so 1) you know the syntax and 2) the install/configuration time would be reduced.

As for the skinning via css. Of course, I really didn't think about it that way. That makes absolute sense. I'm excited

Any thoughts on using an internal viewer vs launching external apps? Case in point, I've always wanted to have a text file viewable (not necessarily editable) just by clicking on it. Probably have it by default only read 100 lines or somethjing similar (configuarable of course). Just a curiosity.

I'll help in any way I can.

skinning via .css sounds interesting to me as well.
Count me in graphically then , me and qoa could so something worthy for this promising project

Two pieces of input....

1)Dual pane view like 2XExplorer - The only real reason I ever found to use anything besdies explorer as a file manager.

2) Gear this project towards 2000/XP. - How much longer is 9X going to be around anyway?

Don't know if this applies, but... If you type into the address bar and hit Ctrl-Enter, the web address formatting is applied. In the Run... box, no dice. Any way to make this work in the Run... box?

addendum: If you need someone to road-test for accessibiliy, my hands make me an ideal candidate. I'm NOT a programmer, but I have a working knowledge of css, a vague one of xml, good with graphics, and am more than willing to help.

I will also help in any possible way. This is an amazing idea I hope too see it through.

Question: If this app is skinnable then would it also skin all the other windows for other programs? (like shellwm does with the titlebar and borders) I don't have a clue what explorer is involved with so I don't know if it controls this....

And I didn't have time to read the entire thing through, so I'm not sure if this is already there but, what about easier, included control over the icons for everything?

And the menus, skinnable?

For documentation, xhtml/css would be perfect, and I happen to know plastic is amazing with that stuff

Talking to some people on IRC, suggestions that if explorer is being totally replaced, better make it a shell replacement too. So I thought, ok, using a skinning engine, this can be (1)File Explorer, (2) Windows Shell [desktop, taskbar, systray, ...] and (3) Windows Skinner [like shellvm].

Of course, this just makes even MORE work, but actually it's not a bad idea. Once the skinning engine is written, it won't be that hard to adapt it.

How much would we need to emulate the microsoft "namespace" idea? By that I mean that I do not intend using the Shell API to navigate the namespace of "virtual" folders, but intend using my own virtual folders. This makes even more work, as things like network folders, printers, control panel and such have to be re-coded from scratch, and I admit some of them are going to be tricky.

Of course, we could steer clear of the namespace idea altogether, and just display files/folders on the local drives. Does this sound too limiting? I thought, yes, we need at least network drives. So if we make one exception, the code is there for more, so we're back at the namespace idea. At least I'll make coding a "namespace extension" hell of a lot easier than microsoft.

and Explicit, of course the menus will be skinnable. One of the biggest requests I've had is to skin the explorer menus. It's so hard it's nearly impossible, so this is the next best thing.

A tool to export registry config to out xml db, sure, of course. It won't be quite that simple though because different assumptions are made. Personally I think that we're going to need a concerted effort of people going through the registry, dealing with individual filetypes, and managing them manually. One of the big problems we'll face is that some filetypes have shell extensions written already, and we don't have the source code. WinZip is an example, but it's quite an easy one. However say Photoshop PSD Thumbnail handlers will be more of a challenge.

Wait a second....did you just say file manager and shell replacement? God bless your little heart. If you guys were to pull this off I would be forever in your debt! I absolutely love this idea. Would everything be plugin-driven? What about plugins to determine how the file file manager worked as well? Like having a thumbnail view like in xp, only thats its own plugin, etc, etc? I'm no programmer and have no time to become one now, but I'd love to help out with this in anyway I can. If there is something I can help with let me know.

Wow. If I were you I'd do one thing at a time. Start with a file manager, work out all the bugs and then move on to the shell related stuff. Just my thought...

On the namespace. I'm leaning towards using the existing M$ ones first (for the same reason I made the comment above). I'm guessing your concern is atht it would be tough to skin? If so, I wouldn't mind having the defaults from explorer style, and then moving into creating your own.

Just brainstorming here, so feel free to discard this approach. I'm just afraid you'd want to take on too much, become overwhelmed and then let the app die. We'd all hate to see it die.

I like the plug-in architecture a LOT!!! I thinks it's a sound model to build off of.

wow.

i get busy for a few days, and a bomb drops on the forum. i'm just catching up on this now.

grigri, you got one hell of an idea there man. that's all i can say about that.

i've always thought that the base for any potential shell replacement should be the file manager. at the core of an operating system is a file system, and running, viewing, and manipulating those files is the basic essential component of any OS. and as such, a file manager can be a shell replacement, and any shell replacement should be a file manager.

as for the project, wow. grigri, count me in. i'd be glad to contribute to any coding effort whatever i could.

That's just great grigri, just the thought of it makes me smile. Will this shell skinner part be able to skin the dropdown menus and scroll bars and buttons and such as well. If it did, this would be just the thing to make customizing windows way less frustrating. Also, when I used LS there was options to change the formatting of menu text...(left, center, right, bold, etc..) Just another idea. P.S as beaker suggested having the default skin emulate regular explorer is really smart, that way if you edit something in the skin you know what your editing, and it will be easier to visualize...

this sounds awesome. and a skinning engine allows for all sorts of aqua interfaces.

this seems like a noble endeavor.

I'm actually quite happy with Explorer. It appears to be rather lean and mean (yeah yeah, appearances can be deceiving), while most replacements seem to be aiming for feature overkill, which I read as bloat.

Sooo, I'd say, whatever you do with it, make it modular, so that people can only load up the bits and pieces they actually need or want to use.

Swell idea actually, that way even people with older computers can enjoy this.

Have you looked at XUL? I know that in the Mozilla project everything from how an interface looks, to how it works is css driven, and that using XUL you can make all sorts of apps. I don't know if anyone has thought of making an XUL File explorer, but it might be exactly what you are looking for. I don't know much about XUL other than it is what is used to build mozilla, and I've seen coders build some pretty neat stuff with it rather quickly. I know it also makes it pretty easy to build custom extensions (modules) so that features can be added by whoever needs them.

I've heard that http://www.xulplanet.com/ is a decent resource for learning about it.

I'm more of a graphics guy myself, but count me in. If there is anything I can do to help I'll be more than happy to.

While I'll no doubt be accused of requesting bloat, being a bit of an icon freak, if you do go through with making it a shell replacement rather than just a replacement file explorer, one thing I would request is that full support be added for 32 bit icons, even in 2K (and, if you do decide to go down that path, earlier, if possible). Since they already exist you might as well implement them properly.

Also for icon labels, text labels that can be any colour, have no background as standard and can be made to not display :>

I'm obsessive about my desktop space...

my my, this does sound like a HUGE project. I love the idea of an XML, xhtml, and css based browser. It has an amazingly great potential for customization. ?shivers? I only wish I could give any input to the project other than, this looks good, or that isn't fast enough, MAKE IT FASTER! my knowledge of XML is nil, and my knowledge of XHTML and CSS is reasonably limited.

On a side note, I make mention of XHTML instead of the soon to be "old standard" HTML. I think if we started off with what's to be the "new and improved" we'd be better off for when M$ makes changes to their existing OS.

?dreams of a completely customizable OS without any icons?

OMG no icons, i love icon. well non-M$ ones

i only wan't or would like three icons on the desktop. like my computer and recycle bin and my documents. or do what XP does and let you choose what ones you want. but with better choice.

What xhtml browser are you talking about fawkes? I was the onlyone that said XHTML because that would be cool for the documentation...

I wasn't planning on using xhtml for the actual browser, just an XSL-based skin/layout file; the actual interface would be rendered programmatically. The XUL sounds interesting, I'll look in to that - it will beat writing one from scratch.

Stop the war on icons! Personally, I like the little beggars, but I know lots of you don't. No worry, the icon-rendering will be in a separate module - choose a template that doesn't display icons and they won't be loaded, so no bloat. No-one will have to put up with bloat from unneeded functionality. For us icon-lovers, though, there will of course be 32-bit icons on all platforms

This is still way in the planning stage, I'm working on a lot of other stuff right now [a few contracts, hopefully more to come]. Once my website is up and running (yeah, I'm registering it as we speak) I'll put up an interactive page for this project, accepting suggestions, working the basic framework. I'm not coding anything this huge without ample planning!

I guess using the term "xhtml browser" was misleading. I was just thinking that the "strings" or whatever was used to name various items would be stored in a text file, (like an .ini file). This way renaming them would be incredibly easy. Imagine being able to tweak anything in windows using only notepad or wordpad for those larger files.

Imagine also formatting allowed in those strings. When a menu calls up the module for "my computer" it refers to a line in some .ini file somewhere. On that line have some incredible simple tags to edit.

#!My Computer <source for icon="path to file/file1.ico"> <display name="root">
#!Control Panel <source for icon="path to file/file2.ico"> <display name="settings">

etc.



wouldn't something that easy be a plus?

Why would you call it xhtml if the code looks like that though?

I see what you mean fawkes, but that's XML, not xhtml. And you're right, the structure for holding filetypes [and even file lists] will be XML.

this all sounds awesome. I can't wait until this project gets up, and running! Sounds like a lot of fun.

For XHMTL I was thinking more along the lines of the UI. Some of us have used HTML in the UI. Whether it be the AmpBar or variations of the Squarebar, etc. It'd be awesome to have a webview which is editable in such an easy format as xhtml. Or grigri's own HTML taskbar (which doesn't work on my machine for some odd reason)...

I'm just imagining having ultimate customizability (made up word) with something so basic as XHTML.

I would prefer a webview that was editable by a WYSIWYG HTML editor. I've been wishing for the likes of this for a long time.

If that isn't possible maybe someone that knows a whole lot about xhtml can invent an editor for webviews. That would be so sweet!

Imagine giving control over webview content to the masses. Crazy isn't it?

xhtml UI? What? XHTML is for making webpages... Not OS GUI's... I think you've got XHTML messed up with some wonderful javascripty DHTML thing...

And what would be the point of a WYSIWYG ebview editor? So you can just add random text and images?

Play nice, Explicit. This is still at the brainstorming/suggestion stage.

I'm just frustrated, these people seem to think that xhtml is the do everything mark up.

I had thought of using xhtml for the ui, as I pointed out in my first post. It would certainly be easier. However, as Explicit points out, XHTML is not really for software ui, although it can be nice (HTML taskbar bits, toolbars, ...). But just in those tiny snippets we've had problems (no way to load icons, ActiveX security warnings, ...).

Nonono, I think it's best if we don't use HTML. But it will definately be similar - the interface will be described in an XML file, and displayed using a custom-built engine. This way, we can ignore all the shortcomings of HTML and specialize for skinnable apps - things like a resizable border (composed of 8 bitmaps - NE,NW,SE,SW and N/E/S/W repeaters) will be handled natively, with mask transparency [possibly even alpha transparency].

As for a WYSIWYG editor, I don't think so. Personally I've no time for things like that, exposure at uni to FrontPage and similar have brought me to the conclusion that they're a complete waste of time, to get proper results you simply have to get dirty with the code. If at a future date, someone else wants to write a wysiwyg editor, that's fine, but I doubt I will.

So, in brief, XHTML out, VPML in. Sounds quite cool, that - "Virtual Plastic Markup Language - the langauge for describing skinnable application interfaces"

well I learned some plain old HTML, and how to use css, but when I took a look at the webview configuration file (I think it was folder.htt or whatever) I didn't recognize anything in it. I read up here on VP that it's an HTML, but I can't even begin to read it.

The reason I wanted to change the webview content wasn't to "add random text and images". It was to have certain folder show links different folders than the common ones that the default Webview gives. I see in the webview a sort of favorites section (I like that idea), but not to the folders that I want to use. I'd like to be able to easily change them to suit me taste.

From what I've seen of XML (Mostly in skin configuration files for various apps) it looks like it would be easier to get the hang of.

Okay, then this would have to be a very specialized WYSIWYG editor then. And alot of that code in there isn't html, thats what I'm getting at. Html and xhtml don't make up everything on these sort of things. Theres DHTML, JS, Scripting etc...

Umm, yeah, but dHTML = HTML + JavaScript, while "scripting" is 95% of the cases comes down to... JavaScript. And xhtml is HTML written in an XML-compliant way. Modern browsers can handle pure XML, with XLS-style sheets and all, but that's not wide spread. XUL, by the way, is XML + css + JavaScript.

Anyhow, it would be highly cool if it would have a completely scriptable interface. Think of the potential!

/me wanders off into La La Land, dreaming of the days to come

Thanks for that.

If you have ever used Gnome they use an XML base. Look at the source for Gnome desktop. All of the above suggestions would hog memory. The primary drawback to using any shell other than
explorer is that they use a ton of memory. Explorer does not use much other than system memory this is its ONLY advantage. Don't just rely on multi threaded programming to do the task it can and does fail. The connection to the fs should be in real time. The metadata about what exists could be driven by XML. BTW XML is faster and lighter than a relational DB if used properly. Its only drawback is that in a large signal model as you propose you would need to code a transform/db engine. Could be done but it needs a balance between what currently exists as API and its relevant application here.

VPML hehehe
I'm still confused about the scripting part. I see how a base for a GUI can be derived from an XML document. But you need a way to connect the elements together, like: if I click this -> this thing appears or these elements are selected. This could be done in lots of different ways and with lots of degrees of complexity, from mimicking the way the webview currently does it (javascript+Object hierarchy) to completly disabling it.

Expanding on the shell replacement part:
Will I be able to make the HTML in the taskbar pages in that language you're proposing to make? I'm guessing yes, and it would be easier too. If that's the case then I should point out the awesome modularity that HTML in the taskbar offers, being able to load pages (->modules) in different resizable/moveable and independent sections of the UI. But these sections can also be combined in toolbars that holds them together.
If there was a way that these sections could not be limited to being squares with non transparent backgrounds it would be sooooo great.

Hosting a scriting language in an application isn't hard, we could always do that - handle javascript or vbscript. Of course, if we're going whole hog and believe we can do better than microsoft, we might as well code out own scripting language [vpscript?]. That sounds stone cold crazy, and it might well be - I doubt even in my best form I could write a script parser that approaches the speed of microsoft's, unless it was really basic. So using javascript is probably best.

kmr, I think you're missing the point here - since the entire shell interface is xml-based, there only is a taskbar if you decide there is! If there is, and you want it at the bottom of the screen, with a start button and tasklist and systray, fine - all will be configurable.
And as for them being squares with nontransparent backgrounds, I say "phragghh" or other such similar unparsable - every display-thing created in VPML will be able to be mask-clipped or alpha-blended with a full alpha channel. Begone grey squares!

Now I'm wondering about the skinning system architecture. I think, for performance reasons, the "skin" file(s) will have be compiled from XML+bitmaps to some internal format. Unless we allow it engine to run in "compiled" and "interpreted" mode, then we can have both...

I've only read the first post, but here are some thoughts...


Ideas:

Import Context Menus - an import utility to create and update from the registry would make the transition easier. The ability to pick and choose items is essecial.

Title Details - The status bar is a waste of space, and the title bar can be too. Combined, they make more efficient use of the space.

Menu Bar Optional - I like the option WinT created to show and hide it in explorer. That's a must, and great for minimalists like ourselves. Having that information displayed configurably would be optimal.

Native Skins - Buttons, if not the whole interface, should be skinnable. Hacking is fun, but let's make things simple. At least have the images easy to find. I would like to see things you've done like menu and tree skinning included too.

Native Webview - I think that the webview system like system through skinning would be nice to have, and much more flexible. Also, it should be lighter.

A couple of things ... you are a brave man (i think) and I applaud you're efforts. I worked on a failed linux shell (like gnome, kde) that was based in XML, it was used everywhere. icons were svg's, had an XML-based registry. It failed though; not saying that yours will. Ours was a school project.

One thing to mention, though. I really hope that it works on win98se ... and here's my reasons. for those who don't know further evolutions of windows are going to be harder to integrate this sort of thing into as microsoft tightens its grip. i've read longhorn revolves around digital rights management and all this other crap that you don't really need. 98 works fine for me and if it ain't baroque, don't fix it. the problem as i see it is that everyone jumps on this XP bandwagon for ease of use (they don't understand how computers work and are too lazy to learn (I like to know what my computer is doing and why and be able to stop it from doing things that i don't want it to)) or they switch over for interface enhancements (the psuedo-skinability and alpha blended icons).

which brings me to my final thingy ... if you are going to make it html-based, icons should be png's like in linux. and thus if you know a little photoshop you can make alpha-blended png's. this could be a problem if you're gonna use IE as you're viewer like in native windows webview. my recomendation is use mozilla (firebird) ... something open-source and standards compliant, unlike IE which despite it's on version 6 (compared to 1 of the other guy) doesn't support half the features without embedding gay active-x controls.

fin ... this is the end of my rant. thank you for your time.

-zick

Hey I'm not missing the point, I just wanted to point out how cool explorer + HTML in the taskbar is, and how it would be awesome if VPML was inspired from the way it works. I must say it again: Resizable without editing text files, allows grouping, Moveable, and can fixed to screen edges or not.

Agreed. Make it as open as possible.

I'm not a big fan of compiles skins. Main reason: can't take them apart and a decompiler would still mean I'd have lost all comments etcetera.

But how about an "on change" compiler thing? Whenever a skin/theme gets selected, the engine will compile it into some kind of optimised form, which it will store somewhere and use until another theme/skin is picked.

hot topic.

it's been interesting, following this thread. very interesting, in fact, to see a reflection of what people want in, basically as it comes down to it, a graphical shell / user interface.

the way i see this progressing so far though, has been from the idea of forming a project to build a powerful, skinnable file manager replacement, into building a whole shell + the entire building blocks for that shell.

which is absolutely great, would be a noble effort, and one that i'm sure many here would be glad to throw their combined efforts into.

however, after the last time i got through reading this thread, and rereading all the most interesting bits, i was left with this feeling:

that would be one monster of a project.

seriously, while a shell replacement with an integrated file manager that is completely xml based and 100% skinnable would be enough for many of us to trade in our first-born for, is that size of a project feasible to start with? remember, grigri's initial post was the description of an idea for a file manager replacement, and even he admitted that that alone would be a huge project.

'dreams create great works, but great works are not created by dreams alone...'

i guess that i'm just concerened that the wish list for this project will grow to a size where the project itself becomes difficult to even begin.

Would be nice if we could create our own artificial center just as windows does, some of the other crazy ways it shows things in duplicate place. Desktop is a prime example.

in re: to craeonics,
possibly use compiled skins for speed, but have a base developer skin that is super-commented or something ... allow developers to post dev and compiled versions of skins.

yes methodik,
it is huge and your fears are viable concerns ... kinda what happened to my shell proj. may i make a recomendation. get a sourceforge (or something simmilar) account that way development can be tracked and help this DREAM become reality.

to grigri,
it'd be nice to have system variables available to javascript or html ... sorta like the *.htt files. like %DIRPATH%, %SYSTEMROOT%, etc.

i've got a couple ideas for some:
%FILENAME% = file's name w/o extension
%FILENAMEXT% = file's name w/ extension
%FILETYPE% = file's type definition listed in the xml registry
%FILESIZE% = file's size in bytes (possibly have other versions of this var to define how to display size or maybe xreg setting)
%FILEATTRIB% = general attrib (for picture files this could be pixel width, etc. ... this might be hard)

maybe even the ability to build dlls that correspond to certain file formats like mp3's that define other var's like %MP3TITLE% or %MP3ARTIST%, etc.

Unfortunately, system variables (like in htt files) are little more than preprocessor statements - it makes things like backslashes hard to manage.

I think it would be better to expose an object in script that would have the necessary information - similar to the 'document' object in HTML. Then you just say "Folder.Path()" or something to get the path, similar for file sizes and such. This also makes extensibility easier.

This is indeed a huge project. So huge that it'll have to be broken down into subprojects from the start. One of these, and a huge one, will be the "skin engine". Others will be the "namespace" and another the "filetype database". The difference between these 2 is that the filetype database defines the types of file, folder, and other objects, whereas the namespace defines where they are.

A subtle but annoying problem will be choosing descriptive names for these objects - trying to avoid confusion will other similar projects [like the actual shell]. Alternative monikers will have to be found for "folder", "filesystem object", and so forth.

It's really nice that so many people are interested - the popularity of this thread is impressive, and only goes to show that this endeavour should have been started a long time ago

Gri-folders & Grifilegrisystem griojects maybe?

I think that for things that are the same or virtually the same, the names should be left. A folder is a directory is a folder. Filesystem object is something I'm not familiar with, so all I can tell you it that it isn't a directory.

I'm just putting in my plug for VBScript support. I'm using vbs now for some automation and I'd be awful happy if I could put the knowledge to use here as well.

It would be nice to use the names we're used to using in code. Red's alternative of griFileSystemObject (or vpFileSystemObject) is a real good idea as well.

I was just wanted to reiterate my fear that this will become so big that it never starts (as others have pointed out as well). I know this point has been brought up by many people, but I think it's a fair one. We should focus on one aspect at a time (but keep the big picture in mind).

The popularity of this idea really is encouraging

I think you're right. I see purpose for another thread. One which focuses on what should be donefirst and leave this one go to gather more ideas and direction. A short-term thread and a long term-thread. Grigri is the only person with the write and knowledge to start it though (not my place to divide a thriving thread). From there, a step-wise plan would be nice.

when can we expect a beta or any images of this. or is it way to early for that?

/me chuckles

come on - hurry up!

deathmedic3rd I guess you missed all the posts about how this is a planning discussion, and how this is going to take a very long time. Please don't rush grigri...

i'm not trying to rush it, just i have to remeber you lot proberly don't have as much free time as me. too much

Then grab a book on coding and help him out.

i would but i own codeworrier 6 and if i try to learn something as complex as coding, i'll forget it if i don't keep doing it.

any how i find coding confussing most of the time

I'm toying with different implementations of a skinning library at the moment... I'll post an example when it's ready.

In the meantime, keep the ideas flowing - the more the better

First off, I'm a vc++ 6 guy so if want i'd see what i could schedule in.

In explorer when you right click>view you can view different view types (thumbnails, details, etc). What I would love ot have is a view "console" idea...which would give you a console prompt IN that directory. Furthermore it'd be nice to add some *nix command line programs such as 'grep'.

Yah, definately - however "nice" the graphic UI, having command-line support is a must. However I was thinking more along the lines of FSO javascript (with some specialized functions), with intellisense (or my rendering of it). Or maybe the option to switch between command line style and OO style.... with intellisense all the same (saves having to use the '/?' flag all the time).

What do you all think?
copy c:\a\folder\*.txt d:\another\folder
or
fso.Files("c:\a\folder\*.txt").CopyTo("d:\another\folder\");
?

The first is a LOT easier to type and remember, but that's because I:
1) know dos
2) don't know js

If I were writing code, I'd prefer the second. Perhaps even in a shorter version:

<filename>.copyTo(<elsewhere>)

Since copy is something which only happens to files, me thinks. Or even:

<filename>.copyTo(<ftp-address>,<login>,<password>)

Some kind of wrapper to integrate ftp-ing and what not into mere copying.

Red has a point though. If you say "console" people will expect DOS and DOS-commands.

...you keep talking about js css and xml what client or server type app are you going to run this on? Before the push for features and shell ui goodies the foundation has to be set otherwise it will just be bloated eye candy. Instead of focusing on the extras memory use has to be discussed and XML schema needs to be developed. The eye and or feature candy is secondary to those issues.

BTW using an scripted fso to handle copy file chores? Scripting can do alot but it does have its limitations....Are you sure you want to make dependent on a virtual machine?

If you'd read the entire thread SOD you'd have seen that making a solid foundation is the n? 1 priority, hence the references to optimization and the this-is-faster-than-that comparaisons.

Everyone (including myself) is quite aware that functionality is more important than features and eye-candy (read the post about not having to load icons if they're not going to be displayed). This thread is merely a place for people to give suggestions.

I'd quite happily discuss memory management, XML Schemas, data structures, multithreading, and so on, but unfortunately most people here wouldn't follow; there are too few coders. A bit later, when my new website gets sorted out (temp problems with the host not providing ASP components), I'll set up several message threads on it for this project, one of them being code-related.

Of course, if you have any interesting suggestions of a technical nature, rather than vague negative statements that are of no use to anyone, please feel free to post them.

Oh, and of course the file chores won't be based on script! The script/console window will just allow users to enter commands that will activate the real routines. And no virtual machine need be involved as most scripts only call methods of COM objects - something that is handled transparently in js through the IDispatch interface. The slight speed cost of invoking a late-bound method is negligeable when that method is going to take time to execute - such as a copy routine.

I'd be happy to help any way I can.

P.S. Any word on removing the yellow banner from you HTML toolbar, remember me? :-)

thanks the more the merrier

Bad news about the HTML toolbar, check here. It's not really top of my list I'm afraid, but I will get around to it eventually...

I stopped by to add my 2 cents (i wrote a quick desktop.ini guide a few years ago)

I just wanted to say that what ever is decided should be simple. I'm no great programmer, making litestep themes is about the amount of work i want to do. I'm all for making the interface scripted but if it takes too much time to do something simple i'm not going to bother.

For this software to be popular out of the gate it will need to support for a large number of the already available extensions for explorer. (Target from win95 powertoys, sfv & md5 calculation and checking, winlinks from Thirty4 Interactive, attributes context menu sub-menu, DMEX) and you should be able to disable all of them if you want.

Now i really like the integration of ie & explorer. I like to be able to use the windows interchangeably. Should make it an IE replacement as well. (with built in explorer bars like 'IE Doc Mon' & 'Source Tree' and some other toolbars?)

I remember when winamp3 was first coming out they were working on the wasabi architecture, and they were tauting it as fully customizable and extensible. Maybe that is the way it should be done? or have i gotten things totally mixed up?

Custum icons for open and close, backgrounds, etc would be nice. Might need a gri.ini file indipendant of the normal one. It would allow for more flexability.

Are thumbnails planned? I'm not requesting, just curious (I use dedicated image viewers for that).

I think for an ambitious project, it needs to include the possible in the near future such as the program able to start in a USB drive and send the operating system(on a cd or dvd) in a memory space(RamDisk) and run your programs from the hard drive,(Program Files folder on the hard drive). That would be fast computer and you wouldn't have to worry about skinning or xml slowing it down.

Guys, just shout if you need any webspace/ftp space in the future, I may even be able to knock up a lil' site for ya

Well they were not vague general statements and all anyone can talk about is the UI side I realize there are some neat suggestions here but what needs to be addressed is the core of the application ahhh..nevermind.
///EDIT///
OK had time to rethink myself. At work I have the task of proof reading/ fixing code, maintaining project files and XML development. These job assingments have made me detail oriented. I guess I just see a lack of organization good ideas could get lost. Or worse scope creep. Should a Wiki be considered for project development?
I would be very interested in the XML development of the app.
BTW have been researching this. I have to for work.
http://www.sleepycat.com/products/xml.shtml
Its the Berkley DB software.
sorry if I came off negative.

js is not native to windows is it? Doesn't it need a runtime?

now in the last little while of catching up on this thread, i've realized whereabouts the seeds for this explorer replacement have come about. i seem to remember another thread here where various ideas for shell extensions were tossed about, and grigri had posted the idea of a console window / script window in explorer.

of course in linux such things sort of exist rather easily seeing as most of the graphical file managers are simply just graphical wrappers for the exact same text based commands; allows the ability to have a console window in a pane that updates as you grphically browse files or, flip it, has the graphical file browsing automatically update as you navigate inside the console.

i gotta tell you, especially in linux with its plethora of commands available, that integrated console / graphical file manager is absolutely wonderful, and allows for some real powerful ability - best of both worlds if you will.

i would go for a window that allows both the usage of normal command syntax, as well as a script based interface for those who wish. of course it goes without saying that you should be able to use such a console pane / window in total sync with the graphical treeview / listview portion, and be able to use either exclusively without needing to use the other if so wished.

in fact, i envision that in much the same way as your standard explorer has two panes, a tree view and a listview with the ability to turn the treeview off, the new explorer replacement should not only have three panes ( the third being the console ), but also the ability to turn any of them on or off as so pleases.

just imagine, a skinnable graphical file manager that can also run as simply a console / script window.

wow.

Well, js is not really native to windows, however the functionality I've described is not limited to js - it's how the Windows Script Host architecture works. Most versions of windows get the dll (scrrun.dll) included but it's available as a free download from microsoft.

I'm working on a draft for the XML-side of things right now, I'll post it when ready. All comments appreciated

It seems everyone wants a console window - ok, there will be a console window. It's decided, definately!

Support for existing explorer extensions is doubtful. Making the framework flexibile enough to both emulate explorer and run itself would not really be feasible. Instead, we'll have to duplicate the extensions adapted to our explorer. This sounds hard, but one of the mail goals of this explorer is to be easily extensible - Windows Explorer is difficult to extend, that's why each new extension seems a micracle in itself.

Must think of a name, too Any ideas?

A name... me thinks real hard.

how about useful shell? j/k

grigri shell a very simple name

Personally I wouldn't make this a shell replacement. First of it would be a lot of work, just think how long LiteStep and other shell replacements have been in development. Maybe it would be a good idea to collaborate with the authors of other shell replacements, maybe to offer better integration.
The whole explorer replacement sounds good though.

I use LiteStep and have done for a long time now and really I doubt that I'd move away from it. Of course I don't represent every alternative shell user but this is just my opinion.

"I'm working on a draft for the XML-side of things right now"
Are you starting with a root document that maps drives and network addys?
Schema is an option not sure about the pros and cons for a large signal like an explorer model. The data load is going to be intresting to see. Consider this, allowing part of the explorers XML
structure to be public. That is a shared resource. With XML you could map different resources and manage file actions remotely. A virtual folder that could be use to manage a file list or map entire hierarchys. he he a virtual data base shared from other explorer users. The encryption could be blowfish. Can you imagine the remote ~real time data possibilites???????
About script:
I have done a thing or two with VBS. My point was they all rely on a runtime be it VBS or JS.

Shell is a commonly misused term, and we don't want to add to it. This is NOT an alternative shell. If anything, it's the final peice to end dependancy on crash-prone explorer (my personal reason for not liking it). We can replace the shell and the browser, but the file manager is still mainly explorer.

I think a simple, one-word name that sums up the progect nicely would be:
Extensive

:which has a nice ring to it in my ears. What it can do and will be able to do will be extensive, and so will it's possibilities for growth. "Extensive Filer" is move indicative to it's purpose with more words, but the same pointedness. What do you think GriGri and pplz?

Red, I like it's simplicity as well as capturing the essence of what GriGri's after...

Well, that's two votes. Curious to here what grigri, wint, and plastic have to say about it.

It does have a nice ring to it, definately

SOD, the start-point for the explorer data will just be local drives. I'll extend this to include network drives in the first instance, then probably FTP after that.

I'm not actually working on that part of things, I'm working on the XML database of file types - equivalent to the file class keys in the registry. The file/folder part of it I'll do afterwards.

This is just a comment but rebuilding the registry is a HUGE project.
How do you support all the applications that associate themselves with the registry not to mention the intrinsic keys that are OS related? If it is going to be just a copy of what is already there it is useless. An abstraction of the registry is just another layer and serious bloat. The argument should be not weather or not you use the registry but HOW you use the registry. I would like the explorer to be designed with a namespace for the registry and have metadata from new deleted and modified reg keys/values appear as folders from within the file explorer. It is unproductive and bloated to operate two registry hives. There has to be a marrage between OS and shell.
Before this gets to far you should define scope....Good luck

/me votes for 'extensive' good name idea red.

I don't think you're going to be able to talk him out of the registry idea. I don't know the details, but he does. It's one of the points to the app.

Meth & gir: thx

Sounds great... and ambitious!

One problem I'm always having with Windows Explorer is that it tends to crash, particularly if I've been using IE and/or the Windows save-file dialog box for more than a few hours. So obviously stability is a key concern of mine.

Of course I could upgrade to XP or Linux, but it would be nice if I could continue to use Win9x -- will your replacement for Explorer improve upon it's instability, or is it an inherent flaw (i.e. more due to the OS than the file explorer function)?

Great idea, hope your project proceeds... I can offer beta testing if you want it.

this is more like several comments all bunched together, so it is kinda long:
I like the idea of this, and would like to contribute whatever I can

here's what I understand so far

it would be at the least a replacement file explorer and it would be completely modular, and it would be styled by a combination of xml,css,javascript

I have used visual c++ for a while and I believe that you can retrieve directory contents by some function in some windows.h file and they are returned in a container class
you can also access any key in the registry and retrieve it's information in a class

a way to implement this filebrowser could be to create an application that supplied the ability to skin everything that it used and could load modules in the skin files
this would make it so that one person could have an xml file that loaded a module that just showed a console and parsed all the data that was given to it by displaying just the text and allowed only 1 input and only by keyboard, while at the same time another person could use another xml file that loaded a menu bar object (controled by an xml file, or by the dll that was loaded), an address bar object, a folderview object(or several),and a status object

mabye the xml(or xsl?) file would load modules and tell the application how they should look and how they should interact

this is a possible idea for an implementation:

basic things that would be needed to get this off the ground
1) a lot of planning before any programming is done (mabye set up a forum just for the design, something simaler to how slashdot is set up with main ideas on a main page and all replies indented right below whatever they are replying to, so that someone could get into exactly what they want and focus on just that information)
2) a basic app that can read and allow interactions between xml files
3) a set of xml files that would be something like defaults and could be customized by the end user
4) a set of default modules that would be used by the default xml

this could be set up like so:
/startdir/
    mainprog.exe
    mainxml.xml
    modules/
        menu1.dll
        bar1.dll
        address1.dll
        viewer1.dll
        status1.dll
        p(m)ng.dll
    style/
        default/
            main.xml
            menu.xml
            bar.xml
            address.xml
            viewport.xml
            status1.xml
            status2.xml
            images/
        style1/
            main.xml
            address.xml
            viewer.xml
            ...and so on
mainprog is executed and loads mainxml.xml which contains something like this:

<style>default</style>
<apptitle>Extensive explorer</apptitle>
<settings splash=false startmax=false getcolorsfrom3dcc=true>
</settings>

this tells mainprog that the style is to be loaded from style/default/main.xml which could contain something like this:

<module>
<name>menu</name>
<dimensions top="0" left="0" height="50" width="%{progID.width}-51">
</dimensions>
<interacts>addressbar</interacts>
<interacts>viewpane1</interacts>
<interacts>%{progID}</interacts>
<interacts>status2</interacts>
<uses>menu.xml</uses>
</module>

<module>
<name>status1</name>
<dimensions top="0" left="%{progID.width}-50" width="50" height="50">
</dimensions>
<interacts>status2</interacts>
<uses>p(m)ng.dll</uses>
</module>

<module>
<name>bar</name>
<dimensions top="51" left="0" width="%{progID.width}" height="100">
</dimensions>
<interacts>addressbar</interacts>
<interacts>viewport</interacts>
<interacts>status2</interacts>
<interacts>%{progID}</interacts>
<uses>bar1.dll</uses>
<uses>p(m)ng.dl</uses>
</module>
... and so on

this file would say to load the dlls that would be used by this style
and specifics about each module would be found in the xml file defined by the module name
for instance in menu.xml you could have something like this:

<align horiz="left" vert=top text="horiz"></align>
<font>%{sysmenufont}</font>
<object text="file" onclick="menu()" text="vert">
<object text="&New" onmouseover="menu()">
<object text="&Window" onclick="%{progID}.new()"></obhect>
<object seperator></object>
<object invokes="viewport.selected.getmenu()"></object>
</object>
<object text="properties" onclick="viewport.selected.getproperties()"></object>
<object seperator></object>
<object text="close" onclick="%{progID}.exit()"></object>
</object>

<object text="help" onclick="menu()" text="vert">
<object text="index" onclick="%{progID}.helpdlg()"></object>
<object text="about" onclick="%{progID}.aboutdlg()"></object>
</object>

this would have more but I hope you get the idea by now
all this xml is based on stuff written for windows media player so I am not sure if it is really xml because I know how well microsoft adheres to standards it sets

this is a representation of the idea I have of what is being stated here,
I would be interested in helping out wherever I can.

here's a couple good ideas:
while we are working with HTML as the general framework, what about mouseover and onclick icons. instead of having that annoying little dotted box show what icon is in focus, why not use a mouseover icon. this is great for us keyboard navigators. when you select an icon for execution, maybe show it in an onclick state. also maybe extended file attrib's and overlays ... like a lock for locked (read-only) files, or hot files, etc. like in *nix.

keep up this cool work ... sounds real good.

also something i thought of last night ... you spoke of inheretence with files ("GIF file" is-a "Image file" is-a "File") ... what about something similar for directories: "MP3Directory" is-a "MusicDirectory" is-a "Directory" ... this way what i mentioned above, with hot files and the like, you can apply the same logic to directories as well. all directories give you copy/paste ... DocumentDirectories (eg "My Documents") give you print all files or something ... music directories give you "burn to cd" or "play in Winamp" as well as whatever regular folders have.

it'd be a real sweet idea for directories to have the same sort of inheretence. could add to creating a level of functionality that could be real useful, like zick pointed out, for mp3's and the like.

Definately, yes

The thought had crossed my mind (I've been trying to do this in explorer) but I hadn't put it into words.

Excellent idea

Hello,

I have just read this topic and man, it's huge. I'm always happy to hear an idea for replacement for the explorer. Speaking about self-contained explorer replacement, I know there's GXExplore which is not so much using explorer COM. Could I give some of my wish list please

1. How about interface like those in Linux box, nautilus maybe ?
2. Command line panel, like in SciTE. There's a hidden panel delimited with a horizontal line that when the horizontal line is dragged up, the console opens up and we can do anything we can do in command line, including some curses like editing (running vim for example).
3. Virtual file system, like mounting zip or tar.
4. Don't use the registry to save settings.
5. Directory size. I always have the problem with space . And it's be nice if there's an info panel that when you select a foldel, the total size is shown. Also there's an option to show folder size in the list panel.
6. Viewer panel for quick viewing of text and image files (for the text viewer, you can use scintilla then we'll have a great explorer and a programmer editor at once).
7. Any good of using client-sever since you're using xsl.
8. Quick folder and files creation, like some icons on the toolbar that when dragged to the panel creates a new folder, file, or shortcut. Don't have to wait for that long context menu to appear to create folders, etc.

Thank you.

again, i'm voting for that sycronized command line access.

grigri, how are you making out with this anyways? are you at any sort of a stage where anyone can join in and help??

Just came here to suggest something about overlays, but zick already did it I'd go one step further, though, and suggest customisable overlay conditions rather than just extended ones, although I'm not entirely sure how that would be achieved.

hmm, if this is going to be a shell replacement i was wondering if i couldsteal moment of your time. i was reading up on some stuff over on arstechnica some time about about a spatial finder. there came a comment about being able to open a folder, and then drag the window over to the side of the screen so that it docked. now this should not make it expand across the entire side of the screen but more glue it there in the same way that the playlist in winamp is glued to the main window.

now if you could say hit a icon on the window and have it slide into a tab state (basicly all that was showing was a tab with the name of the folder) that when clicked would have the window slide out and show the content of the folder.

now if i was to browse up to the same folder in the folder tree on the disk the folder should not show in that window but rather make the tabbed window slide out. basicly signaling, hey im over here

its basicly a total bastardisation of the spatial finder idea, the original wirter would have had me shot if he ever read this

Sounds like something you have on the Mac. On the Mac you can dock your Finder window (Finder is the Mac's file manager) to your screen edge and have it displayed as only a tab. Dragging something over it, or clicking on will will make it pop open and it will automatically slide back again when done.

Quite a cool concept.

hehe, it was a mac article i liberated it from
to bad no existing explorer relacement out there have a feature like that...

in fact i dont even think there is a desktop system on linux that have copyed that feature yet. hmm, maybe its time i learn how to code c++ and start adding it to kde

Does anyone know if grigri is actually working on this?

"working" might not be the relevant word... I'm afraid I barely have enough time for small unpaid projects at the moment, something of this magnitude will have to wait for a bit.
It's annoying, because I really do want to make this a reality, but unfortunately I have to eat and pay the rent, so "real" work takes precedence

hkmm, maybe a opensource project would be in order for something of this size...

http://slicker.sourceforge.net/ <- nice...

This here is incredibly long...it would be nice if all of the ideas here could be collaborated into some sort of an organized document because I don't even know where to begin here and reading this all is like reading a book except it's not organized...I don't even know where to begin commenting on my ideas. : )

I have just been somewhat inspired to take up coding, and will be buying a cb book and looking for *cough* Visual Studio.

I have read this whole thread and have two main ideas.

1.) Full Import / Export Support

This would be great. If you are talking about buildable menus etc, import and export support would help an unbelieveable amount for support for the maker, sharing the resources and back up and overall functionaly.

2.) Then the second is from remembering Avat where I first fell in love. Multitab browsing. I think 90% of the time, I have more than one instance of explorer running, and think multi tab browsing would be a great idea if not to hard to implement.

I am offering my services ;l if needed. Beta testing, alpha testing, help writing documentation etc.

Will be checking back here often,

Advance

tabbed browsing for a file manager would be so useful!

Advance, there are plenty of free IDE's out there. You're not stuck with Visual Studio.

Hate to be off topic, but do you suggest any?

In the next month I would be interested in getting some help with a project that I have already started. To help you will need to learn XUL (the markup language used by mozilla firefox) and its related languages.

My project is originally for my software engineering class so I cannot release code yet(my prof requires that we have no outside help) but as soon as we hand in something for the semester we will be opening it up under the MPL at the following link:
https://sourceforge.net/projects/gecko-fbrowser/

The advantages of using gecko (the backend for firefox) over a propietary solution are numerous. For example if we wanted to make the program work in OS X it would be fairly trivial (we are currently estimating that it would require changing about 5 lines of code, every one of them a system call). The same for porting to Linux, or any OS that Mozilla runs on for that matter.

Advance, sorry I didn't see your post earlier. For .Net development, I've heard great things about #develop. Latest release was 10 Nov 04, so it's still in active development.

For C++, Dev-C++

I can't remember what VB6 app I had heard about back in the day and I couldn't find it . I'll keep looking, though.

However, it seems M$ has released an express version of the .NET 2005 IDE. I haven't tried it, so I can't claim just how good/bad it is.

And as always, the obligatory plug for AutoIt. It's it's own proprietary language, but it can compile exe's and has a very active community.

fallout,
sounds like a good idea.
i've been talking to some folks over at mozillazine about the development of a mozilla based shell. it's a good idea whose time has definitely come.

i know a little xul and i might be willing to help, so keep us informed.

so basicly the entire desktop would be renderd by gecko, just like the firefox gui is now. hmm...

it would allow unquestionable flexiblity with menus, dialogs and a whole lot of other stuff. but would it not be one hell of a memory hog?

i've never sat and analyzed xul in that way ... but considerring that the browser is actual written xul and it runs faster (IMHO) than ie ... well, you do the math.

i thought of something that might be nice to and actually take some strain of the system. icon/cursor/sound theming. instead of writing registry keys for what icons or cursors or sounds to use, lets just adopt a formatted pattern and stick with it ... like for icons (ex. c:/windows/newShellName/icons) you would have a "default" directory that would store a png (or ico, whichever is faster) that is named after the file extension, like jpeg.png for files ending in jpeg (you could also use jpe.png and jpg.png for files with those extensions, etc.) ... cursors (ex. c:/windows/newShellName/cursors) would have a "default" directory that stores png's and mng's (or cur or ani, again which ever is faster) that are named things like arrow.png, busy.png, wait.png, hand.png, brace.png, cd.png, etc. and these correspond to certain cursors displayed automatically during certain tasks ... again same applies to sounds (ex. c:/windows/newShellName/sounds) with wav's or mp3's named startup.*, shutdown.* logoff.*, error.*, critical.* for specific sounds.

now after the default directory, you can add another theme by copying "default", renaming the directory and replacing the files (retaining the same filenames). maybe you can even add an info file to the root of this directory that contains author info, long name, version, etc.

very *nixy

I can't contribute to things like coding, but I can add suggestions.

Okay, it's like this, Explorer has been done, done, re-done and re-done again. The taskbar has been done... The system tray has been done... It's all been done and it was boring at the start and still is. All the shell replacements, except a few are just boring Explorer clones. Done, done, done. The most promising have at best, abismal documentation and/or crash, reliably. Also, all I see in the shells that show even a pinch of promise is, "Windows '98 only" and/or "Site Not Found" when I try to look them over. I use XP, contrary to popular belief, it's actually usable, when it is made not to look like it was designed visually on the Gay Pride website. When you disable all the services that have no purpose, it seems, other than to consume system resources it runs like a scalded cat. One of the best current shells I've seen costs money, and not a small enough amount to convince me to use it over Explorer.

One might be asking, "okay, loudmouth, what would your shell look like?". Easy, and compared to the current crop of boring Explorer wannabes, probably easier to code. Seeing as how the smallest monitor these days is 17", screen real estate should not be a problem.

What would be a title bar at the very top, 20 - 25 pixels, would really be a system resource, TCP/IP IO indicator, clock and calendar. Much like Uptimer:

http://www.geocities.com/merijn_bellekom/new/uptimer.html .

Below that, a menu bar, again 20 - 25 pixels, similar to a Mac, but fully programable to launch all your applications, accessories, games, utilities, etc. One "un-programable" menu would be a task/system menu that would scroll when the vertical limit of the desktop is exceded. Oh, pitch the icons in the menu bar, they consume resources and most people know how to read. The ones that really need icons, don't know how to use a computer, anyway.

These two "modules" should be in an "always on top'" mode.

Finally, an optionally skinnable desktop with a built in wallpaper changer, and an option to turn off the icons. Same reason as above.

That's about it, looks real easy.

Happy Holidays.

go buy a mac

or better yet, install linux and use kde or gnome...

Now just wait a friggin minute. I don't put myself in the same league, but it seams to me Einstien got the same crap from his peers, as did Edwin Hubble, Nichola Tesla and countless others. If they'd taken that advice or just simply sit down and shut up you wouldn't be tippy-tapping on your keyboard there, you'd be using a qwil and parchment to express your ideas.

Furthernore, what if the software or equivelent I use doesn't exist in Linux, yet?

And, buy a what? 1) I don't want to spend $3000+ for hardware that can't do any more than my Athlon, on Windows XP, no less, for $2000+ less. 2) I don't want something that looks like a refrigerator, inverted plunger or a plain old TV set.

By the way, I already use Linux. Problem is, it seams all the current window managers are Explorer clones, done, done, done. That aside, Linux rocks.

Right now, I work nine hours a day and don't have time to learn the intricacies of programming or shell hacking to make what I want, so, I express my ideas to others who can.

At this point, I feel I've wasted enough of my valuable time explaining myself.

Have a nice day, Hob...

if you think they all look like explorer clones then you have not looked realy deep into the ability to put anything on any bar, anywhere.

basicly the "start" button on both kde and gnome is a quickuse icon with a submenu, and can be moved around just like the others. the task area is a bar applet that can be moved around just the same, and so on...

they may look like explorer clones out of the box but thats just for ease of use. if you realy use linux then play around with them a bit, i bet you will be surprised...

why are you guys talking about shells? this was originally a filemanager thread.

I'd really like a filemanager like emelfm, for windows. Its basically two identical explorer panes, side by side with a CLI underneath. An option to double the CLI area as a preview/editor area for files that are text based, ie. .txt .htm .bat .reg .doc .ahk would be really useful too.

sryo, the explorer filemanager is allso the explorer shell in windows. basicly the desktop is just a folder presented is a "special" way by explorer...

serenity, what you are describeing is a classical layout from the dos days, know either as norton commander or midnight commander. nothing new, but sometimes very usefull

some more ideas ...

adopt a new start/taskbar format; my idea is based kinda on gnome's wharf. so you have this bar, right (height and width can be specified in pixels and percents as well as positioning left, right, up, down) that can be specified whether it's visible or not or whether it'll hide itself when not in use. kinda like the startbar now, but that's where the similarities end. you know how you can add toolbars (lists of shortcuts usually in a folder) kinda like the quick launch to the taskbar, right now. think about this for a sec. what is the start menu but a folder of shortcuts only m$ tells you what goes in there and what icon it has and what text is on the button. so we give the new shell the ability to create "drawers" like the gnome wharf and these drawers act as pop out start menu's, as many as you want with the text and icon that you want. you want a real start menu but you want to call it the "steve" menu and put an icon on it that's your face. done! and with like a little ini in the folder where the "drawer" stores it's shortcuts. let's look at a practical example:

for the sake of an arguement "c:\newShellName\drawers\" will be our root directory. so lets make a "start" menu. you put a folder in there and call it whatever you want. place an icon named default.ico or png and your shortcuts into the folder and then add the drawer to your taskbar namespace ...

which brings me to another point, the namespace. the namespace tells the shell how to divy up the space provided to the bar. lets say you want a couple different drawers. you would specify the drawers display order from left to right (or if the shell is configured for a left-handed it goes in the opposite order). the namespace would probably be xml like this.

<namespace type="dock" width="100%" height="72px" orientation="bottom">
// other orientations are left, top, right
// dock can also float by specifying a specific pixel width
// (or a percentage other than 100) and an x and y coordinate

<drawer width="200px" display="1" arrow="1" name="Steve" icon="default.ico" tip="tooltip string" dir="%drawerRoot%\steveMenu\" />
<drawer width="250px" dir="%drawerRoot%\steveApps\" />
<application width="*" link="taskman.exe" />
<application width="250px" link="systray.exe" />
<application width="100px" link="clock.exe" />

</namespace>

now you can add pop-menus and applications right to the bar. and i don't know if this thing will ever get big enough to have its own dev environment, but maybe applications built with this shell in mind could specify a "dock" view of the app that cuts down the fluff of the app so it can fit on the dock, like a media player may have a dock view that is just the playback buttons and maybe a little text field for the title of the song playing, while that app's full view might be totally different.

ok im THINKING that firefox could be a very good platform for grigri's
"File Browser" i have looked in
"C:\Documents and Settings\user\Application Data\Mozilla\Firefox\Profiles\ackk51qd.default\" and it look s like grigri's
project could be done as a tweek project to the "chrome" GUI of firefox
useing firefox as a explorer replacment would be So CooL

and in theory more bloat then explorer...

I've always thought the file viewer, the taskbar and toolbar, and the desktop should be handled by separate exe's, and that there should be a watchdog exe on the file view. The task panel should in the file viewer should be an Explorer bar, and the browse mode for opening each folder in it's own window should strictly enforce "one folder, one window". Hitting the Folders Icon or selecting View| Explorer Bars|Folder which opens the Folders explorer bar shoud also toggle the window between "open each folder in it's own window" mode and "open each folder in the same window" mode.

http://vebwiev.tripod.com/ builds on functionality that was available in Windows 98, but missing in Windows XP. It would have less duplicated effort if the file explorer worked with this.

it's not free but I switched to Directory Opus http://www.gpsoft.com long ago.. explorer sux.

Fully agree. I even prefer metapath. The only thing you can't do with it is copying from one window to another: the second sets its path to the first one's. But it's minimalist and lovely for navigating and running apps.

Just to mentain another minimal file manager,
Miniexplorer http://members.tripod.com/dj_tow/minex.htm

The creator supposedly designed it to be like Dimension File manager.
It has no toolbars and a left double click on the background, causes it to go up one level in the directory.

But otherwise, its mainly like explorer.

Another one: http://bradlima.com/index.php?page=tabbyFile

Free with tabs

CubicExplorer is a file manager with a tabbed interface and integrated search functionality. You can quickly access your favorite folders by creating custom categories with shortcuts to selected folders. The program offers a clean and easy to use interface, but other than the tabbed display, there aren`t many features that set it apart from the standard Windows Explorer.

more information and donwload : http://www.cubicreality.com/

Free No Tabs but :

JExplorer is a dual-panel type file manager and web-browser as well. JExplorer has many features such as file manager, web browser, compressor/decompressor, folder comparator, FTP clent, POP3 email checker, image capture, chareacter regnition on the image, virtual drive mounter. JExplorer is a freeware and it runs under Windows 95/98/ME and Windows NT4/2K/XP.

more information and donwload http://home.megapass.co.kr/~woosjung/

shareware

Docsvault Pro with tabs:

Docsvault Professional is a document management software that enables you to store all your important documents in a central repository, organize them into cabinets and folders, track changes via audit trails and version history, burn selected documents to CD/DVD and more. You can import paper documents directly from your scanner and automatically convert the scanned document to PDF, TIFF or other digital formats. The program also includes a Safevault that enables you to store sensitive documents like credit card data, bank statements etc. in an encrypted state. Other features include a built-in task manager with reminders and linked documents, integrated document search engine, backup/restore, tabbed interface and automatic file versioning. Docsvault Professional also comes with a PDF printer driver that allows you to convert any document to PDF via the standard print command.

more information and download : http://www.docsvault.com/

RecentX

RecentX keeps track of all files, folders, programs and websites that you use and allows you to instantly access them later, without having to search through history lists or favorites. The program provides a tabbed interface that organizes the recently accessed files by type, and you can further customize the filtering by adding custom keywords, that allow you to quickly filter the history to find specific types of files. When you right-click on an entry in the RecentX interface, you have also access to common file operations such as copy, paste, delete and more.

more information and download http://www.conceptworld.com/RecentX/

woa! thanks for the cubic explorer!

it looks like it will turn into some kind of freeware directory opus. and its allready use the icons i have changes thru icontweaker!!

basicly its doing a lot more then windows explorer would do, and only then if i run it in single "mode" (ie, that all windows are basicly just a single prosess. including the task bar).

and with the planed rewrites to cubix explorer, it can go only one way

hmm, it seems the dev is from finland. i should have know it would take a crasy fin to write somthing like this and give it away for free

as much as I'd hoped to find an explorer replacement
I was looking forward to using the cubic explorer as was
shown above but unfortunately it wouldn't remain stable
on my xp-sp2 system.

it continually flashed and refreshed my directory screen
on the right which made it useless...I was hoping there was some
option to stop it but I couldn't find anything to cure the problem.

I'm guessing it was just conflicting with some other software...
pity because it did look very useful indeed.

Mike.

maybe hit the forum and report the problem...

ok, the dev just had a system crash bit he managed to save his work so...

its still early days for it. alpha stage at best...

i asked on the cubicexplorer forum about the problem and there is the thread:

http://cubicreality.com/forum/viewtopic.php?p=1702

You need to be logged in to post. To log-in, or to register an account go -there.