Ok, I got fed up with some of the limitations of apple's finder and so I sat up, went on source forge and started ChikaraX (Chikara == Power in Japanese). The purpose of ChikaraX is to build a customizable, fast, Cocoa version of apple's finder. I just started, and want to call for thoughts, opinions, rants, anything else as this is just starting the planning stage. Check it out at http://sourceforge.net/projects/chikarax
Or, just post your thoughts here as I am curious for some feedback on this idea.

-Max

cool, but aren't you still going to be limited to aqua?
What are some of the ideas? Are you going to incorperate
some of the old Finders strengths?

Sounds pretty cool...

aqua doesn't offend me like it used to.

I'd try to do as much that the old finder did as possible, which, using the cocoa api's should be much easier than it was for apple to do it in carbon. Big emphasis on customizability, I'd like for the user to be able to switch on and off as many features as possible, from menu transparency (easy to programmatically change) to the preview pane, to the 'finder' font.

I simply do not have time to do this all myself, and perhaps over the summer I will, I'm really hoping that this will grab people's interest and become a rather large effort.

-Max

I guess the practicality of this would depend on a few things:

1) Is the Finder 'just' another app, just like S.J. says it is?

2) Can we replace the finder with any program we like and have it boot at runtime?

3) Will this affect any functionality with power management/drivers/etc

4) Will we be able to get filthy rich by recreating the Finder and selling back to Apple

I'm up for it... I'm a new Cocoa programmer, but you learn by doing, eh?

I'm going to start learning Cocoa soon, and I'd like to join in.

I've always thought that the finder should be able to show a lot more file types. You've got a photoshop document but can't be smegged to open photoshop - so just open a preview in the finder.

Perhaps the preview pane in column view could include a "Bigger" button that brought up a full-size preview of the document. This would include images, pdfs, sounds, movies, etc. The idea of launching a separate "Quicktime player" always seemed silly.

fyi, and to help out, i've posted info about ChikaraX to my forum, Galapagos, which is devoted to Mac OS X / Darwin GUI discussion in general.
http://groups.yahoo.com/group/galapagos-gui

feel free to check it out, participate, or ransack it for beta testers. =]



------------------
heath m rezabek

Galapagos - OS X / Darwin GUI discussion
http://groups.yahoo.com/group/galapagos-gui

this is cool! i like the idea...

What I like about this idea:
-cocoa: I am annoyed that Apple wrote their OS front-end interface in a partially emulated environment. I am not sure how run time compares between carbon and cocoa when it comes to core graphics but I have a feeling that cocoa should be a little faster with some things (all speculation).
-choice: It is interesting to make an open-source OS X shell to allow the more seasoned users to tinker.

What I don't like:
-replacing the finder: As far as I am concerned there are few limitations to the OS X Finder. I would like a few things to be fixed such as resize-to-fit but that is about it
-preview: in order to do what Sadie suggested, you will have to build-in a decoding module for each file type that you want decoded. That could take years. Besides Apple is already on their way to doing this, you are just starting and have less resources.
-Aqua: Many of your ideas (the best ones, at least, like transparency prefs) are not Finder-defined traits. They are defined by the API and I would laugh if you wanted to re-write that.
-fighting evolution: I think that you are just not used to the new Finder. It has many things that the other didn't and it lacks many that the other had. I think that Apple will round it out over time but you have to be more willing to accept change. It is not a coincidence that they called the sub-system "Darwin" (suddenly Tool's 46+2 popped into my head).

Conclusion:
Have fun but don't expect it to do even half of what you are asking. If you have the time you should do it. It would be an interesting projects. Just remember that you require actual OS modifications to do some of what you are demanding and that cannot be solved with a simple application. There is a way to do some of that but I don't know how it works in OS X (not a kernel extension but something else you can build). Things such as window/menu transparency, drop-shadowing, real-time refreshing, etc. cannot just be over-written. This is something that Apple will eventually write into a NSUserDefaults dictionary and then you could change it (and they will add a prefs pane for it). However, I don't know how you could do that without being able to modify the junction of OS and window server when you aren't actually inside the OS.

That is all speculation, though. If you succeed in this, then you will be very well-liked by some users of the OS who prefer the "Classic Feel"

Jeff.

[parallax]

I agree with Apocalypse on all accounts.

It will be difficult to pull off, but a great accomplishment if you can.
It seems like it would be easy to do (Just have a window that displays files and their previews, right?) but it's a lot more than that. You'll have to manage things such as moving, renaming, copying, asking if you want to replace files, dragging things to the Trash, integrated support for iDisk, Connect to Server, drag & drop, launching, saving view preferences, trash emptying, ejecting CDs... the list goes on.

Of course, you won't get all of this in the first run through, but things like planning writing an optimized Photoshop decoding/previewing module are just impractical for a small team to think of at this stage.

Don't abandon the project. If nothing else, you'll learn a hell of a lot of Cocoa.

Contrary to popular belief, Carbon is not emulated at all. In fact, Classic isn't even a proper emulator because it's running native binaries.

I'm behind Apocalypse on everything he said except for the emulated Carbon thing. I think what he mean't is that it's not the purest API for Mac OS X. Ofcourse carbon is not emulated!

------------------
Think Different.

Originally posted by Apocalypse:
-preview: in order to do what Sadie suggested, you will have to build-in a decoding module for each file type that you want decoded. That could take years. Besides Apple is already on their way to doing this, you are just starting and have less resources.

Rubbish, it already has a simple preview mode, but it's limited to the size of the column. Quicktime, for example, is a cross-platform system available equally to every program. It would cost nothing to let this pop up into a window of its own.

We wouldn't be expected to understand, say, 3D Studio Max files. But something like a TIFF should certainly be viewable as a straight image without having to load a specific program.

Oh, and one feature that people really want in a Finder: the way Next had of storing files in the toolbar and dragging them out later to copy them!

I too am not a fan of the new 4K78 Finder. I liked the Public Beta's Finder a lot. It had that cool apple in the center of the menu bar and no list or icon views. I wish there was a way to get the PB's Finder to work under 4k78. I tried to get it to work but there is something different about the PB's and 4k78's Applications. Most of the PB's programs do not work in 4k78. I was really sad to find this out because I wanted to use the Music Player from PB in my 4k78.
Is there a way to like make the beta's apps work in the release version of OS X?

2) Can we replace the finder with any program we like and have it boot at runtime?

Yes, you can. I saw an article somewhere that detailed steps to replace the finder with the terminal. Wierd, but it worked. No reason you couldn't do the same with a different app.

One thing that I'd love with a replacement Finder is the ability to have Power User features that simply shouldn't be part of the regular Finder. Many of these features would be to help with various Unix features that rightly are hidden to the regular user.

My votes:

Command to open terminal at current directory

Direct path field to go to that path ala IE

I love this feature in Windows Explorer (Window's equivalent of the Finder). When you are moving between directories it is very useful.

Better context menus and the ability to pass the file to an Applescript or a Unix command

Originally posted by berk8100:
I too am not a fan of the new 4K78 Finder. I liked the Public Beta's Finder a lot. It had that cool apple in the center of the menu bar and no list or icon views.

In what way did it have "no list or icon" views? What was the right-hand toolbar widget for? ;-)

I know, I know.
I just realized that. But What about my Apple?

I want a dual split column view in one window so i can move and copy
files real easy. Having to open a second window is a pain ; )

Originally posted by berk8100:
I know, I know.
I just realized that. But What about my Apple?

It was pretty, but misleading. Everybody who used OS 9 thought it was a menu, and tried to click it.

Originally posted by sadie:
It was pretty, but misleading. Everybody who used OS 9 thought it was a menu, and tried to click it.

And then any with half a brain realised that it didn't do anything and didn't touch it again. The others (i.e. 90% of the Mac OS 9 Zealots) complained bitterly that they kept on clicking it and generally pissed off everybody else.

I personally don't see what all the fuss was about. I didn't even think twice.

Yup, there are some people that learned not to stick their fingers in the electrical outlet the first time they got shocked.

Somone port the NeXTStep look and feel. Could GNUStep run on OS X?

I just discovered this forum and thought I should mention that I have a replacement for finder fairly well along in development.

It is my learning Objective-C and Cocoa project.

I enjoyed it so much, I bought myself a Cinema Display to continue work on it.

I started on it two weeks ago, so it's only 2,300 lines of code so far.

But it is going well. It does the a view similar to the Windows Explorer that I was very fond of. Tree view of directories on the left, details table view on the right. I just finished up an icon view, (with tighter spacing than finder). And I'm not inclined to do Browser View, which I've never liked for its dependance on horizontal scrolling.

It fixes my biggest complaint about Finder, which is that for unknown reasons, Finder never seems to have a very current view of the filesystem. Especially if Terminal or OmniWeb is creating/deleting files. I download files from OmniWeb all the time, only to go look in my Downloads folder and find that neither the .tar.gz file, nor the expanded directory that Stuffit Expander just created are visible. My file system view is always updated immediately. If you type "touch foo.txt" in a shell, the icon appears immediately in my app.

So far, it does drag and drop moves, (i haven't done right button drag copy yet), it deletes (moves to trash) with a single click of the delete key (another finder peeve of mine), it navigates using the keyboard, up and down arrow keys, enter to launch or navigate sub-folders... There's a "cd .." button, which can also be accessed via the left arrow key. It does all the sorting in the details list view, and I have it keeping folders separate from regular files, the same as WinExplorer... (this can be turned on and off.) It is a multi-document view of course.

Oh, another peeve: if a file doesn't have an extension, and Finder would pop up that awful dialog box asking the user to figure out which application to use, (as if any naive user would get it right), I just open the file and if it looks like ascii text, I load it up in a private TextView. Or I can send it to TextEdit... All these options will be configurable. Since I allow the user to browse /etc, this has turned out to be very handy.

Next I'll be doing more work in my icon view to allow sorting, and keyboard navigation, I'm debating whether to save icon locations or just stick with a grid, ditto on whether to use the resource forks for icon previews, or do my own .files for the icon previews.

I have to do abbreviated names for narrow columns, even though I dislike how finder does it... ALongFilena...blah.jpg but I'm not sure how I'll change that yet.

I want to implement Cut/Copy/Paste for files... currently the Finder just copies the Filenames, which is pretty useless. I also have to implement file renaming in all views.

I'm going to do "Shell Here" as soon as I can find out how to tell Terminal to tell /bin/tcsh to do a "cd $dirname" on startup. Anyone know how?

Then there's a list about about 20 other things I'm going to be doing to it before I release it.

That's about it for me. How far along has this project gotten?

-tw

Originally posted by tom_waters:
I just discovered this forum and thought I should mention that I have a replacement for finder fairly well along in development.

It is my learning Objective-C and Cocoa project.

I enjoyed it so much, I bought myself a Cinema Display to continue work on it.

I started on it two weeks ago, so it's only 2,300 lines of code so far.

Are you serious?

If you are, put me down for 1 copy.

I was wondering, is there anything inherently faster in using Obj. C for the Finder? Or is it just a little more flexible than the Carbon version?

I think most people want a Cocoa Finder because of a speed increase in, well, finding files, and less spinning disks, but would it be any faster than the Carbon version? My limited understanding of Carbon is that it's just as accessible to the system as Cocoa, but Cocoa is just more flexible and more "dynamic" in its loading of modules and stuff, and not necessarily faster when it comes to loading files or processing tasks. Is this a correct assumption?

Dallas

Originally posted by DV:
Are you serious?

If you are, put me down for 1 copy.

I was wondering, is there anything inherently faster in using Obj. C for the Finder? Or is it just a little more flexible than the Carbon version?

I think most people want a Cocoa Finder because of a speed increase in, well, finding files, and less spinning disks, but would it be any faster than the Carbon version? My limited understanding of Carbon is that it's just as accessible to the system as Cocoa, but Cocoa is just more flexible and more "dynamic" in its loading of modules and stuff, and not necessarily faster when it comes to loading files or processing tasks. Is this a correct assumption?

Dallas

I'm serious. I put an image of it running in my iDisk public folder, tom_waters It's called Winder.jpg, or you can see it at homepage.mac.com/tom_waters

I don't know a thing about carbon. The best I can say is that if it is in Cocoa, it should look and feel like the rest of the Cocoa apps.