Designing a new Finder

[OS923]

I have plans for a new Finder.
It will show long filenames in Unicode on HFS+ volumes.
It will be able to display all files and folders in one list view.
Every volume will have its own trash.
Trashed files will not automatically be renamed, so you can put them back exactly like they were.
The views in a window can be mixed, for example an icon view sub-window in a list view window, or an icon view sub-window in an icon view window.
Sub-windows will be merely a drawing like a rounded rectangle with a title bar in the same color as the label of that folder.

First I make a test program to see how fast it will be.
It displays all files and folders in one list view.
It does inline edit in Unicode.
I use caching, R-trees and delayed evaluation.
I'll let you know how it goes.

In the mean time, you may propose a name.
I thought already of a few names:

• Finder+
• Findest
• UniFinder

[MacOS Plus]

  As you might be able to guess, I'm quite partial to the "+" convention.   It also fits well with "HFS+".

[DieHard]

How about...

FinderLives!

or

Finder9Lives!

[Nameci]

My vote goes to Finder+

[DieHard]

Yeah,

Finder+

really is cool and says it all

[OS923]

Findest is a German word, so that won't go.

[OS923]

There are already several products with the name Finder+.

[OS923]

OS 9.2.3 file manager

[Nameci]

How about Finder9+

[nanopico]

Crazy idea.
What if we bundle it with the ROM updates that have been made along with some others that may be coming down the pipe.
And since Apple renamed OS X to Mac OS we call the whole thing System 10.

[MacOS Plus]

  One feature that would really make my day would be if you can sort out how to have multi-line text for files and folders in large icon view.  It has always driven me nuts that many files on the desktop either extend their names out the side of the screen by default or overlap neighbouring icons' names due to the grid spacing.  Either that or the default column alignment for icons on the desktop needs to shift left a bit and the grid spacing preference need to allow a wider column spacing.

[OS923]

I'll add that feature.

I'll add also "Paste as file".

You can follow my progress here:
http://os923.gangstalkingwiki.com/DesignNewFinder.htm

Did anyone ever hear of a WDEF which displays the Unicode folder name in the title bar of the window?

Otherwise I have to write this myself.

Then I search the source code of a WDEF which supports all the messages required in OS 8.5 and higher.

[Enabler]

UltraFinder or PimpMyFinder or SteroidFinder or PlatinumFinder or FinderExtended or FinderUnlimited or
OmniFinder or RocketFinder or SmartFinder

[Metrophage]

FindersKeepers! XD

[OS923]

I search the documentation that used to be on this page:
http://developer.apple.com/documentation/Carbon/Reference/File_Manager/index.html

[IIO]

And since Apple renamed OS X to Mac OS we call the whole thing System 10.

exactly.

i am using OS 9.6 audio final since 10 years now, and it is really about time a for a major update.

[IIO]

Did anyone ever hear of a WDEF which displays the Unicode folder name in the title bar of the window?

i dont think it exists. but if you find it, or if your write one, iīd like to have that available as resedit template/patch, too.

[IIO]

https://developer.apple.com/library/prerelease/content/releasenotes/General/CarbonCoreDeprecations/index.html

[OS923]

That's for OSX 10.5.
But I found what I needed on a developer CD.

[OS923]

iīd like to have that available as resedit template/patch, too.

The WDEF will redirect everything to a function in the program.
When the program creates a window, the WDEF installs a data handle, in which it stores the arguments which remain unprocessed.
Then the program installs a pointer to its function in the data handle.
Then it processes the waiting arguments.
From then on everything is sent straight from the WDEF to that function.

[IIO]

That's for OSX 10.5.

yeah i know, it is just funny that what you can find for OSX is also in "deprecated" status since many years.

soon cocoa will be, too.

time to buy another atari.

[OS923]

I wrote a WDEF which can draw Unicode text in the title bar.
It's just a working WDEF, no bling bling.
Here's a preview with a demo program:
http://os923.gangstalkingwiki.com/DesignNewFinder.htm

[Mat]

Nice!

I downloaded the test program from your website and it "works" like expected.

What I do not understand is the point 4 of your aims: " Trashed files will not automatically be renamed, so you can put them back exactly like they were." When does the orioginal Finder rename trashed fies??

[IIO]

hello world.

hello window!

and what a nice long name you got, with so many wonderous symbols in it!

[OS923]

What I do not understand is the point 4 of your aims: " Trashed files will not automatically be renamed, so you can put them back exactly like they were." When does the orioginal Finder rename trashed fies??

It doesn't, but Sherlock 2 does and in my program Finder and Sherlock 2 will be one and the same program.
Some of my tools will be integrated too, like calculating CRC's.

[OS923]

If the title changes, then it verifies whether it can be converted to MacRoman.
If this is possible, then it draws the title faster using QuickDraw.
The same functions will be used to draw the filenames in the windows.
So if you don't use weird characters, then you won't have any loss of speed.

The WDEF will soon look just like a normal window.

I will omit 2 features because I don't like them:

• There's no proxy icon in the window.
• You won't be able to get a menu by clicking in the window title. The menu has to be in the contents of the window.

I also want buttons for opening the window of the super folder.
A green up arrow button will be equivalent to command + Up.
A yellow up arrow button will be equivalent to option + command + Up.

The program will be incompatible with Copy Agent.
It will replace Copy Agent and do better.
It will allow you to choose how much CPU time may be spent to the copying.

[OS923]

Better Finder
Die Hard Finder
Dream Finder
Ersatz Finder
Finder King
Finder Not Dead
Finder to the max
Finder255
Long Unicode Finder
Real Finder
Surrogate
Undead Finder

I'm in favor of "Long Unicode Finder" because it describes best what it does.

[IIO]

maybe you steal the picture preview from coela or some of the features of gregs browser and add that.
icons bigger than 32x32 and background images would also be nice.

[OS923]

I don't want larger icons.
In fact, there will be an option to turn custom icons off.
Picture previews and background images are good ideas.

[OS923]

How can I use Windows Unicode fonts on OS 9?

www.AlanWood.net/unicode/fonts_mac.html writes:

The WorldText text editor and 2 experimental applications (MLTE Demo and SUE) have implemented the facility to use Windows Unicode fonts under Mac OS 9.

www.AlanWood.net/unicode/utilities_editors_mac.html#mltedemo writes:

This means that it can use the large Unicode fonts that are designed for Windows, such as Arial Unicode MS and Bitstream CyberBit.

I tried those programs, but the Windows Unicode fonts don't appear in the font menu.

[OS923]

I think that I found my mistake.
The Windows Unicode fonts need to have type 'sfnt' and creator 'movr'.
My idea was to use Arial when the text can be converted to MacRoman and to use the Windows Arial Unicode MS otherwise.

[OS923]

The WDEF is now ready for variable font and size and title bar height that can be chosen in preferences.

[OS923]

What do you think of this idea:

Folders on HFS+ volumes are opened in a window with a blue frame, the same blue as the folder icon.
The blue shows that everything is OK.

Folders on HFS volumes are opened in a window with a beige frame.
It's beige to warn you that there are no long file names and no Unicode.
If you copy a file with a long file name or Unicode to a beige window, then it warns you that the name will be converted.
The beige refers to the oldies beige computers.

Folders on FAT volumes are opened in a window with a red frame.
It's red to warn you that there are no resource forks.
If you copy a file with a resource fork to a red window, then it warns you that the resource fork will not be copied.
I find that a better solution than the RESOURCE.FRK folders, because they cause trouble when you use the volume on a Windows PC.

Then I want to re-introduce the file copy with a modal dialog.
In the earlier Mac OS, when you copy, then it showed a modal dialog and you had to wait until it was done and then you could use the interface again.
So if you copy by dragging, then it behaves like in OS 9.
But if you also press the option key then it will first show a dialog.
Here you can choose:

• copy/move (like in Puppy Linux),
• copy/merge/smart merge (like in CopyAgent),
• foreground/background.

If you choose foreground then you get a modal dialog with a cancel button and maximum speed.
If you choose background then you can choose:

• how much CPU time do you want to use,
• wait until x seconds idle.

If you copy in the background and suddenly you want to do something in the interface, then it's practical if the copy is automatically paused as soon as you use the mouse or keyboard, and after x seconds of no mouse or keyboard event, it resumes the copy.
I do that already in the Async tools.

[OS923]

What do you think of this idea:

Hide the contents of the window of a folder that is being changed until there are x seconds of no change.

[OS923]

One of the things that I will have to do is drawing on the picture that covers the desktop (without drawing in the windows).
How can I do that?
I remember that I've seen source code of a program that could draw a rotating Earth on the desktop.
I forgot its name.
I think that it was something like Geo3D or Earth3D but I can't find it anymore.

[OS923]

I found it.
It's called EarthDesk 2.1.

[OS923]

Now I search something else.

What is the fastest file copy algorithm?

The first version of my Async tools worked with seperate threads for reading and writing.
That was 20% faster.

I think that it will make a bigger difference when you copy to a different HD.

Here they talk also about using different processors for read and write:
http://people.nas.nasa.gov/~kolano/papers/lisa10.pdf

[IIO]

i am no a native coder but seperate threads sound logical.

otoh, from what iknow, the most speed gain could be archieved by first finding the space where to write, then write in chunks as big as possible. that is about what OSX does...

[OS923]

In C++ I have best results with blocks of 16k.
First I do SetEOF which tries to allocate a contiguous block.
In REALbasic I have best results with blocks of 32k.

[OS923]

I found it.
It's called EarthDesk 2.1.

No, wrong again.
I think that it was more like Planet Earth.
(I looked at version 2.0.3.)
It could draw on the desktop, with source code included.
What I need is probably called DeskHook.
But it may not work in OS 9.

https://groups.google.com/forum/#!topic/codewarrior.mac/7VsWe0q-1C4

I went to update my animated desktop (wallpaper) thingee and discovered that
"DeskHook hasn't been supported in many releases of the Mac OS and has been
removed from Carbon". This is certainly a true statement as far as 9.04 is
concerned. I put a Debugger() call in my DeskHook routine and it never even
gets called.

Does anybody know of a replacement? It wouldn't necessarily have to be
Carbon. I could muck around with however X does it.

Does anyone know the prototype of a DeskHook?

[OS923]

Here's the prototype:

Code: [Select]

#define DESKHOOK (*(void (**)())(0xA6C))But what does it mean?

[nanopico]

It looks like a call to get a handle to an A trap system call.

[ProfileName]

This is an interesting project. Curiosity:
What program do you use to create this app?
You mention the features of your app, what is the main idea?
Here's my suggestion: NextFinder

[OS923]

I write it with CodeWarrior Pro 5.3 without PowerPlant.
The main idea is that the old Mac OS was designed in a time that memory was very expensive, so they sacrificed speed for memory.
I want to sacrifice memory for speed.
I also want to solve some technical problems like long Unicode filenames.
For example, if you have a long filename, then it will be displayed like "abc#A14.txt".
The number A14 will change when you copy the file to a different volume, which is hilarious.
This may also change the order of the files, which can cause problems if you want to compare files and folders.
So if you copy files with a long name, then it will warn you.
It will warn you about possible problems.
For example, if the Finder flags say that the resource is locked, but there's no resource fork, then it may not be possible to unlock the file.
There are many of these problems which my Finder will see, warn for and/or repair.
Another example: if you copy pictures from a Windows computer, then you may also copy invisible locked files with the name "Thumbs.db". These files also cause trouble on OS 9.

[OS923]

i am no a native coder but seperate threads sound logical.

otoh, from what iknow, the most speed gain could be archieved by first finding the space where to write, then write in chunks as big as possible. that is about what OSX does...

I tried it and it works well for large files, but not for small files.
Synchronous IO with large files and large blocks was 3x faster than Finder.
Synchronous IO with small files and large blocks was slower than Finder.
Asynchronous IO with large files and large blocks was 1.5x faster than Finder.
See the results here:
http://os923.gangstalkingwiki.com/DesignNewFinder.htm

I also improved the WDEF.
As you can see, I can use Windows Unicode fonts.
(Noto was converted to Mac TrueType.)

[OS923]

FastCopy has the solution:
https://ipmsg.org/tools/fastcopy.html.en

It automatically selects different methods according to whether Source and DestDir are in the same or different HDD(or SSD).

• Diff HDD: Reading and writing are processed respectively in parallel by separate threads.
• Same HDD: Reading is processed until the big buffer fills. When the big buffer is filled, writing is started and processed in bulk.

Reading/Writing are processed with no OS cache, as such other applications do not become slow.

And... it's open source.

[IIO]

I tried it and it works well for large files, but not for small files.

you could get the file length first and when the file is longer then 20 mb you use method B.

[OS923]

For example, if the Finder flags say that the resource is locked, but there's no resource fork, then it may not be possible to unlock the file.
There are many of these problems which my Finder will see, warn for and/or repair.
Another example: if you copy pictures from a Windows computer, then you may also copy invisible locked files with the name "Thumbs.db". These files also cause trouble on OS 9.

That's not accurate.
Thumbs.db files are invisible, but not locked.
But I have experienced trouble with invisible locked files.
I think they were icon files.
The problem with locked files that couldn't be unlocked occurred like this:
the "Has been inited" flag is set but there's no resource fork.

[OS923]

I wrote a program which can copy asynchronously between 2 disks, where write can get behind on read. In debug it can get behind and then there's a marginal benefit. In release it doesn’t get behind because the reads and writes are perfectly alternating so there’s no benefit.

Thus the FastCopy solution which is fast on Windows won't be fast on a Macintosh.

Then the solution is probably: copy small files asynchronously with blocks of 16 K and copy large files synchronously with blocks of 64 MB. Now the question is: what is small?

I tried a HD with a buffer of 2 MB and one with 8 MB. The second was 20% faster.

Is here someone who uses OS 9 with a HD with a buffer of 16 MB? How fast is it? Can you measure that with the hard disk toolkit?

[IIO]

in a realtime situation you might use the HDīs buffer for more than one task at a time.

btw, copying many files at once compared to one by one is slightly faster on mavericks, about the same speed on 10.4.11 but much slower on OS9.

i even managed to chrash the OS9 finder sometimes with folders of 3000+ files, with both, copying and unstuffing.

[OS923]

That type of crash is prevented by my "Flush within a second" extension.

[IIO]

The problem with locked files that couldn't be unlocked occurred like this:
the "Has been inited" flag is set but there's no resource fork.

why should this cause trouble?

[OS923]

What I do not understand is the point 4 of your aims: " Trashed files will not automatically be renamed, so you can put them back exactly like they were." When does the orioginal Finder rename trashed fies??

It doesn't, but Sherlock 2 does and in my program Finder and Sherlock 2 will be one and the same program.
Some of my tools will be integrated too, like calculating CRC's.

That's not accurate.
I mean if you move several files with the same name to the trash, then Finder will refuse, but if you try this with Sherlock 2 then it will rename them.
If you move a file to the trash with the Finder, but there's something in the trash with the same name then that item will be renamed.
So it's not the trashed item which is renamed, but the older item with the same name.

[OS923]

Now that I know how Finder uses AppleScript I decided that the new Finder will support only open app, open doc and quit.

You will be able to install your own plugins in the new Finder, for example if you want something else than list view and icon view.

The things that are usually done by FKEYs, contextual menu extensions, scripting additions, control strip modules or even extensions should be done by plugins in PPC code.

I had also these ideas:

• sending an Apple event which contains a complete script to the new Finder is much faster than sending numerous Apple events which contain one command.
• merge DrScheme into the new Finder.

[OS923]

It's possible to replace AppleScript with Scheme if the new Finder and a Scheme extension are linked to the same shared library with a shared data section. Then you can write scripts for Finder that work at the speed of a C program instead of the speed of AppleScript.

Then there's one major problem left: drawing on the desktop.

[OS923]

I wrote an extension to find out how Finder draws on the desktop.
It covers the desktop with a window which doesn't draw a white background.
It's a 'normal' window.
That's why Finder comes to the foreground when you click in the desktop.
First it draws the background pattern, then it draws icons in its special window, which are painted on the background pattern.
That's why it's a bit flashy.
The special window is drawn between BeginUpdate and EndUpdate.
When you move an icon, then it's drawn outside BeginUpdate and EndUpdate.
When you quit Finder, then the special window continues to exist, but it's only updated when you click in the background.
When you restart Finder, then it makes a new special window.
The content of the special window matches GrayRgn.
The visRgn of the special window is GrayRgn - the sum of the other windows, regardless of the window order.
So if I make my own special window, then the content of Finder's special window will be the empty region and it will draw nothing.
Then the 2 Finders can be running at the same time.
Just a theory.
I didn't try it yet.

[Protools5LEGuy]

Better Finder
Die Hard Finder
Dream Finder
Ersatz Finder
Finder King
Finder Not Dead
Finder to the max
Finder255
Long Unicode Finder
Real Finder
Surrogate
Undead Finder

I'm in favor of "Long Unicode Finder" because it describes best what it does.

What about "Findr" instead of anything longer? I think most of us are interested in displaying more options, gaining some space loosing the "e" from "Finder". "Find" could be fine too, but "Findr" seem easy to recognize versus Apple's Finder and MacTronīs Finder

[OS923]

At this moment it's called UniFinder because this is practical.
All Unicode classes start with Uni (UniString, UniWDEF and so on).

[MacTron]

... and MacTronīs Finder

ŋ?
 

[IIO]

At this moment it's called UniFinder because this is practical.
All Unicode classes start with Uni (UniString, UniWDEF and so on).

like

[IIO]

Then the 2 Finders can be running at the same time.
Just a theory.

watch out for situations with loops and buffer underruns.

eventually just forbid two copies to run at the same time.

[Protools5LEGuy]

... and MacTronīs Finder

ŋ?
 

You did an Finder that could "Quit", and were called MacTron's Finder IIRC

[it0uchpods]

Hi all,
This seems like a cool project, I'll suggest the name Finder++? With 2 pluses? UniFinder is also nice.

I personally use 9.2.2 on my TiBook (Onyx), so I'd be willing to help test, and maybe contribute if I can.

J

[OS923]

I'm trying to define everything in plugins that are linked to the same library as UniFinder.
This library UniFinderLib goes into the extensions folder.
You can replace the plugins by writing your own plugins using the SDK.
UniFinder is merely a program which loads plugins and dispatches events and manages threads.
The easier things like drawing or sorting are done by plugins.
The plugins are open source.

I tried this for the first time in 2000 but I wasn't good enough and I also made the mistake of trying to do everything in 3D with QuickDraw 3D.

I wrote several programs that will be integrated in UniFinder:
Make a list of the full paths of all aliases and their targets.
This can later be used to repair all aliases.
I tried it and it was flawless.
I can also rearrange the CodeWarrior editor windows without opening the files in the IDE at the speed of about 200 files per second.

At this moment I'm rewriting the part of PowerPlant that I use for OS 9.2.3.
It's ridiculously much work.

[DieHard]

I wrote several programs that will be integrated in UniFinder:

If you have time, can you elaborate on 1 or 2 or these programs and their purposes...

[IIO]

Make a list of the full paths of all aliases and their targets.

this is very cool, but canīt most search programs do that, too? (filebuddy?)

[OS923]

I had also another idea for aliases but I didn't try it yet.
Save a unique number in the Info comment of every target and save the same number in the corresponding aliases.
These numbers can be used to repair the aliases.
This has the advantage that I don't have to change those files and I don't have to record anything and the numbers are copied when you move the files to different disks.
What do you think of it?

[Apfel]

Better Finder
Die Hard Finder
Dream Finder
Ersatz Finder
Finder King
Finder Not Dead
Finder to the max
Finder255
Long Unicode Finder
Real Finder
Surrogate
Undead Finder

I'm in favor of "Long Unicode Finder" because it describes best what it does.

What about "Findr" instead of anything longer? I think most of us are interested in displaying more options, gaining some space loosing the "e" from "Finder". "Find" could be fine too, but "Findr" seem easy to recognize versus Apple's Finder and MacTronīs Finder

At this moment it's called UniFinder because this is practical.
All Unicode classes start with Uni (UniString, UniWDEF and so on).

What about LUFinder. Allthough "all Unicode classes start with Uni" is a good argument fo UniFinder. I also like Findr in favour of saving space.

"Findest", german means "you (1st person singular) find", would describe only a slow portion of what the Finder does, just like using "find" would do. ("Find" would also be confusing like a meaning a "search" button).

---
RE: copying multiple files, how is this actually handled, when you start several folders at once or you start a second etc., while one is still being copied? I guess the heads of the HDD will jump back and forth instead of first writing one file complete and then start copying the next, right? The last option would probably result in a less fragmented HDD, right?

[IIO]

in macos 9 it is handled like this: the paths are collected and written into a queue, then the files are copied one by one (as if the user would copy them one by one), and each file is copied from the beginning the the end.

unlike OSX, in which: the paths are collected and written into a queue, then it is made sure that the target volume has enough space, then the files content are copied all at once, and (as far as i can vaguely describe it) the chunks of the content are copied in a random order (i believe the order is based upon what the HD finds the fastest, at least in <10.9/HFS) and when everything is there, the data is finall made files again.

this is why OSX is sometimes 2x faster for copying files and there is virtually no limit of how many files you can copy (while OS9 finder can crash when you copy thousands of files at once)

[IIO]

These numbers can be used to repair the aliases.

What do you think of it?

the idea sounds right and i am hardly able to find something which would be contradictionary.

there are a few things which come to mind, which might interfere:

 - "get info" is already used by some other apps, for example photoshop&co like to leave some info there, which is then also used by some other apps to display the info to the user later.

 - transferring files over a network can remove the "get info"

 - rebuilding the desktop database or repairing volumes can remove the "get info" stuff, at least when the user chooses to do so.

but none of them would make the function completly useless. you normally dont create aliases to pictures files and if your volume is damaged you couldnt care less about the get info comments.

[OS923]

in macos 9 it is handled like this: the paths are collected and written into a queue, then the files are copied one by one (as if the user would copy them one by one), and each file is copied from the beginning the the end.

unlike OSX, in which: the paths are collected and written into a queue, then it is made sure that the target volume has enough space, then the files content are copied all at once, and (as far as i can vaguely describe it) the chunks of the content are copied in a random order (i believe the order is based upon what the HD finds the fastest, at least in <10.9/HFS) and when everything is there, the data is finall made files again.

this is why OSX is sometimes 2x faster for copying files and there is virtually no limit of how many files you can copy (while OS9 finder can crash when you copy thousands of files at once)

I can define file copy in an open source plugin. If you want to do it your way or like in Windows, then you define that in your own plugin.

I can imagine that you prefer a Trash like in Windows, so the Trash should as well be defined in a plugin.

[IIO]

of course in this case it is almost an obligation to include one option which is called "copy files exactly like apples finder would do".

[OS923]

I published intermediate problems and solutions on this page:
https://www.gangstalking.eu/problems/index.htm

[OS923]

I found the solution for drawing on the desktop.

I looked into the PandoStickers 2.0.2 extension. It draws on the desktop by patching FillCRect and FillCRgn. (This works only if you remove the desktop picture.)

I could imitate this and patch DrawPicture too. Then it should work also with a desktop picture.

This is an easy solution which avoids patching DMDrawDesktopRect and DMDrawDesktopRegion which are 2-word inlines.

I didn't try it yet but it should be a formality.

[OS923]

At the top of a window, there's an area which is wasted with not so useful information like "10 items, 59.1 MB available". I want to use this area better. This is a good place for buttons and menus. I want here a menu for changing the view options. A menu for the path has to be here instead of in the window title. I want a button for opening the super folder. What else do you want here?