Per folder settings, .DS_Store tech discussion

[Anonymous]

Hi...

I have setup my "standard" finder window with columns, at the bottom of the screen, certain height, width, etc, etc.

When I goto File / New Finder Window, I get this same setup.

BUT when I click on folders on my desktop, they open as smallish, squarish, icon-only views that just show the contents. I don't use these windows for file manipulation in the same way as I use my "standard" setup.

Until I can have that in Pathfinder, it can't replace the Finder. It's just too much for me to have the folder windows be the same big "show me everything" type of setup I use in my "standard" window. I want a different sort of view.

I assume having this ability (different settings for different folders) means a database, possibly not of trivial size.

I assume many people use the finder this way (different setups for different folders), and it forces PF to remain an great application but not a Finder substitute.

My $0.02 : I'd rather see efforts put into making PathFinder a complete, a better Finder than into making it a "universal" addon to Finder that comes with built-in apps for a zillion tasks.

tom

[Anonymous]

First off, there should be a way to settings specific on a window-to-window basis, like in Apple's Finder. Like, you should be able to set the icon size and stuff, and have it only apply to that window.

Also, it would be nice to be able to set individual icon sizes. I believe this was a hidden feature in Jaguar, but it was completely scrapped in Panther.

Another idea would be to steal the Windows XP feature of having "Picture Folders" and "Sound Folders" etc. You would have to look it up for complete details, but it is one of the main features that makes the XP Explorer better than the Apple Finder.

Also, would you be able to eliminate Panther-esque icon highlighting and use the Jaguar method? It looks much better to have the icons simply shade in (although Path Finder pulls off the box-method much better, especially when using Labels).

Well, thanks for reading. Great job on Path Finder! I use it almost exclusively now.

[Anonymous]

Heh, you should strike up a deal with Apple to have Path Finder included in the next release of their OS. You'd be rich, and it would benefit OSX.4 greatly.

Hah, just a thought.

[Monkey Angst]

First off, there should be a way to settings specific on a window-to-window basis, like in Apple's Finder. Like, you should be able to set the icon size and stuff, and have it only apply to that window.
I agree with this. Path Finder should respect .DS_Store settings from Finder... when opening a CD, for instance, if the CD manufacturer had a nice little setup where his icons are on a background at a certain size in an unadorned Finder window, PF should do the same thing. This view can be changed by the user if they wish, but PF's pure utilitarianism can use a little eye-candy break from time to time. :)

[neilio]

The problem is that Apple hasn't documented the .DS_Store format, and seems to not have a lot of interest in doing so, which has made things difficult in this regard. Basically speaking, .DS_Store files are not accessible by anyone.

Steve and I have started discussing what the feature list is going to look like for the next release, and this looks like it's at the top of the list. I can't make promises, as things may change, but adding this functionality is definitely high up on the priority list.

Neil

[Anonymous]

I absolutely have to agree here. I love this app and after 2 days use trying to replace the finder, the biggest need is infact that PF cannot remember display settings for given window, also PF should be able to remember individual last size and window positions like the Finder does. Then its a no-brainer.....Kepp up the great work guys.


Peter

[quico]

There's an article at http://www.macosxhints.com/article.php?story=20030305025744788 that discusses Finder views and .DS_Store files in detail.

I came across this forum post because I was wondering if Path Finder manages or creates .DS_Store files on file servers. We avoid using the Finder on our unix file servers here because of all the .DS_Store files that get created. It sounds like from this post that they don't get created.

A feature that I would like to see in the future, assuming Path Finder is able to use .DS_Store files, is to have the option of disabling the creation of .DS_Store files on connected servers. If I was assured of this feature I'd make it required of my system admins to use Path Finder when connecting to our file servers.

[knghtbrd]

An advantage of the column view in Finder (which I am told is the most common view for people who consider themselves to be novices) is that it doesn't create the .DS_Store files.

Some tools, I know Cocktail is one, can delete all of the .DS_Store droppings left behind by Finder. I am considering submitting a hint to macosxhints to detail a unixy method for getting rid of them. Your UNIX server could easily do the same, and probably should actually.

The command I'd use is something like...

find <dir> -name .DS_Store -print0 | xargs -0 rm

You can actually use -exec instead if you know how, but people who don't understand some of the esotericisms of find and bourne shells tend to get confused by it.

[quico]

I actually want to keep the .DS_Store files on our unix server. We keep the image of our mac os x clients there and there are several folders whose icon and window position needs to configured a certain way.

Ideally, I setup the image using the Finder which creates the .DS.Store files and then when I'm browsing the image on the server I use PathFinder because it won't overwrite the .DS_Store files that need to remain unchanged.

[knghtbrd]

I see, you just don't want the settings you set to get changed. Does making them 0644 or 0444 have any effect?

[neilio]

I'll have to confirm with Steve on this one, but I'm almost positive that using Path Finder as your network volume browser will not leave .DS_Store files. This is because it's the Finder that writes these.

I guess this could be a selling point for people who hate those files littering their Windows servers, huh? (scratches beard, makes diabolical face :))

Neil

[quico]

I think it would be a very good selling point. If you haven't done so already should do a search on .DS_Store on google and you'll quickly realize what a headache they can be.

[Anonymous]

.DS_Store files are evil. If Path Finder ever opts to customize views per window, it should store the settings in a single database in the user's preferences.

[knghtbrd]

The disadvantage of this is that if you mv the directory (in UNIX or with Finder or with something else), you will lose your customization, and you will have a stale database entry. .DS_Store has neither problem.

[Durandal]

That's true. It's more of the way the Finder handles views I hate, not so much the idea of putting everything in a .DS_Store file itself. If Path Finder handled them in a more intelligent manner, I wouldn't be against it, especially if Path Finder could respect disk image window states, background pictures, icon placements, et cetera. THAT would be cool.

[neilio]

...especially if Path Finder could respect disk image window states, background pictures, icon placements, et cetera. THAT would be cool.
This is all on the to-do list for when we do implement per-folder states. This is really high up on both the feature requests list, as well as our priority lists, so it should make an appearance sooner rather than later.

Neil

[ecammit]

Correct me if I'm wrong, but moving a folder/file keeps the same inode number for the file/folder. It is only copying the file/folder in which the copy gets assigned a new inode number. In this case a central database for the user saving window sizes could be associated with the inode number. In this case moving a folder would not result in a loss of window positioning, but instead a copy of the folder would lose all positioning. I would consider that acceptable.

[knghtbrd]

Correct me if I'm wrong, but moving a folder/file keeps the same inode number for the file/folder.

That's a reasonable theory, but fails when you move folders across devices. Coders have to act like they're paranoid or things break. ;)

[Anonymous]

I have also noticed that quiting the finder and just using PF. In Safari's download window normally allows you to click on the magnifiying glass and show the file in the finder. This breaks when you quit the finder in PF. This need to be addressed. Any app that hooks to the finder need to be hooked to PF. I don't think this is an easy task, if PF is to be a true finder replacement it need to work.