Mac OS 9 Lives

Classic Mac OS Software => Hacking the System, Mac OS 9.3, and Beyond ! => Topic started by: OS923 on June 24, 2016, 04:53:28 AM

Title: Designing a new Finder
Post by: OS923 on June 24, 2016, 04:53:28 AM
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:
Title: Re: Designing a new Finder
Post by: MacOS Plus on June 24, 2016, 11:06:00 AM
  As you might be able to guess, I'm quite partial to the "+" convention. ;)  It also fits well with "HFS+".
Title: Re: Designing a new Finder
Post by: DieHard on June 24, 2016, 07:25:58 PM
How about...

Quote
FinderLives!
or
Quote
Finder9Lives!
Title: Re: Designing a new Finder
Post by: Nameci on June 26, 2016, 07:03:29 PM
My vote goes to Finder+
Title: Re: Designing a new Finder
Post by: DieHard on June 26, 2016, 10:39:46 PM
Yeah,
Quote
Finder+
really is cool and says it all
Title: Re: Designing a new Finder
Post by: OS923 on June 27, 2016, 06:10:13 AM
Findest is a German word, so that won't go.
Title: Re: Designing a new Finder
Post by: OS923 on June 27, 2016, 06:14:14 AM
There are already several products with the name Finder+.
Title: Re: Designing a new Finder
Post by: OS923 on June 27, 2016, 06:14:38 AM
OS 9.2.3 file manager
Title: Re: Designing a new Finder
Post by: Nameci on June 27, 2016, 04:53:35 PM
How about Finder9+
Title: Re: Designing a new Finder
Post by: nanopico on June 27, 2016, 08:12:11 PM
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.
Title: Re: Designing a new Finder
Post by: MacOS Plus on June 29, 2016, 09:16:17 PM
  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.
Title: Re: Designing a new Finder
Post by: OS923 on July 04, 2016, 06:42:31 AM
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.
Title: Re: Designing a new Finder
Post by: Enabler on July 04, 2016, 04:50:20 PM
UltraFinder or PimpMyFinder or SteroidFinder or PlatinumFinder or FinderExtended or FinderUnlimited or
OmniFinder or RocketFinder or SmartFinder
Title: Re: Designing a new Finder
Post by: Metrophage on July 04, 2016, 07:40:17 PM
FindersKeepers! XD
Title: Re: Designing a new Finder
Post by: OS923 on July 06, 2016, 03:03:16 AM
I search the documentation that used to be on this page:
http://developer.apple.com/documentation/Carbon/Reference/File_Manager/index.html
Title: Re: Designing a new Finder
Post by: IIO on July 07, 2016, 04:52:44 PM
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.
Title: Re: Designing a new Finder
Post by: IIO on July 07, 2016, 04:54:49 PM

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.
Title: Re: Designing a new Finder
Post by: IIO on July 07, 2016, 04:58:33 PM
https://developer.apple.com/library/prerelease/content/releasenotes/General/CarbonCoreDeprecations/index.html

:)
Title: Re: Designing a new Finder
Post by: OS923 on July 08, 2016, 06:02:53 AM
That's for OSX 10.5.
But I found what I needed on a developer CD.
Title: Re: Designing a new Finder
Post by: OS923 on July 08, 2016, 06:10:12 AM
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.
Title: Re: Designing a new Finder
Post by: IIO on July 08, 2016, 02:50:45 PM
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.
Title: Re: Designing a new Finder
Post by: OS923 on July 12, 2016, 06:43:00 AM
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
Title: Re: Designing a new Finder
Post by: Mat on July 12, 2016, 08:02:39 AM
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??
Title: Re: Designing a new Finder
Post by: IIO on July 12, 2016, 02:09:39 PM
Quote
hello world.

hello window!

and what a nice long name you got, with so many wonderous symbols in it!
Title: Re: Designing a new Finder
Post by: OS923 on July 13, 2016, 06:37:55 AM
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.
Title: Re: Designing a new Finder
Post by: OS923 on July 13, 2016, 06:54:59 AM
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:
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.
Title: Re: Designing a new Finder
Post by: OS923 on July 13, 2016, 06:58:12 AM
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.
Title: Re: Designing a new Finder
Post by: IIO on July 13, 2016, 01:14:03 PM
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.
Title: Re: Designing a new Finder
Post by: OS923 on July 15, 2016, 07:11:22 AM
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.
Title: Re: Designing a new Finder
Post by: OS923 on July 26, 2016, 05:03:38 AM
How can I use Windows Unicode fonts on OS 9?

www.AlanWood.net/unicode/fonts_mac.html writes:
Quote
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:
Quote
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.
Title: Re: Designing a new Finder
Post by: OS923 on July 26, 2016, 06:17:03 AM
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.
Title: Re: Designing a new Finder
Post by: OS923 on July 26, 2016, 06:19:54 AM
The WDEF is now ready for variable font and size and title bar height that can be chosen in preferences.
Title: Re: Designing a new Finder
Post by: OS923 on July 26, 2016, 06:46:30 AM
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:
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:
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.
Title: Re: Designing a new Finder
Post by: OS923 on July 26, 2016, 06:54:21 AM
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.
Title: Re: Designing a new Finder
Post by: OS923 on July 29, 2016, 07:23:29 AM
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.
Title: Re: Designing a new Finder
Post by: OS923 on July 29, 2016, 08:44:48 AM
I found it.
It's called EarthDesk 2.1.
Title: Re: Designing a new Finder
Post by: OS923 on July 29, 2016, 08:47:54 AM
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
Title: Re: Designing a new Finder
Post by: IIO on July 30, 2016, 04:50:08 AM
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...
Title: Re: Designing a new Finder
Post by: OS923 on July 31, 2016, 01:59:06 AM
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.
Title: Re: Designing a new Finder
Post by: OS923 on July 31, 2016, 02:03:56 AM
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
Quote
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?
Title: Re: Designing a new Finder
Post by: OS923 on July 31, 2016, 02:13:01 AM
Here's the prototype:
Code: [Select]
#define DESKHOOK (*(void (**)())(0xA6C))But what does it mean?
Title: Re: Designing a new Finder
Post by: nanopico on July 31, 2016, 09:36:06 AM
It looks like a call to get a handle to an A trap system call.
Title: Re: Designing a new Finder
Post by: ProfileName on July 31, 2016, 11:18:45 AM
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
Title: Re: Designing a new Finder
Post by: OS923 on August 03, 2016, 05:00:03 AM
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.
Title: Re: Designing a new Finder
Post by: OS923 on August 03, 2016, 05:16:33 AM
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.)
Title: Re: Designing a new Finder
Post by: OS923 on August 03, 2016, 05:34:44 AM
FastCopy has the solution:
https://ipmsg.org/tools/fastcopy.html.en
Quote
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.
Title: Re: Designing a new Finder
Post by: IIO on August 04, 2016, 11:31:08 AM
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.
Title: Re: Designing a new Finder
Post by: OS923 on August 24, 2016, 06:35:25 AM
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.
Title: Re: Designing a new Finder
Post by: OS923 on August 30, 2016, 07:04:59 AM
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?
Title: Re: Designing a new Finder
Post by: IIO on August 30, 2016, 04:51:38 PM
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.
Title: Re: Designing a new Finder
Post by: OS923 on September 01, 2016, 06:57:53 AM
That type of crash is prevented by my "Flush within a second" extension.
Title: Re: Designing a new Finder
Post by: IIO on September 03, 2016, 03:43:09 AM
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?
Title: Re: Designing a new Finder
Post by: OS923 on September 14, 2016, 08:56:35 AM
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.
Title: Re: Designing a new Finder
Post by: OS923 on October 10, 2016, 07:18:36 AM
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:
Title: Re: Designing a new Finder
Post by: OS923 on October 12, 2016, 07:35:36 AM
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.
Title: Re: Designing a new Finder
Post by: OS923 on November 03, 2016, 07:41:33 AM
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.
Title: Re: Designing a new Finder
Post by: Protools5LEGuy on November 16, 2016, 08:13:38 PM
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
Title: Re: Designing a new Finder
Post by: OS923 on November 18, 2016, 02:35:16 AM
At this moment it's called UniFinder because this is practical.
All Unicode classes start with Uni (UniString, UniWDEF and so on).
Title: Re: Designing a new Finder
Post by: MacTron on November 18, 2016, 09:06:56 AM
... and MacTron´s Finder
¿?
  ???
Title: Re: Designing a new Finder
Post by: IIO on November 18, 2016, 02:59:41 PM
At this moment it's called UniFinder because this is practical.
All Unicode classes start with Uni (UniString, UniWDEF and so on).

like
Title: Re: Designing a new Finder
Post by: IIO on November 18, 2016, 03:03:04 PM
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.
Title: Re: Designing a new Finder
Post by: Protools5LEGuy on November 18, 2016, 06:34:41 PM
... and MacTron´s Finder
¿?
  ???

You did an Finder that could "Quit", and were called MacTron's Finder IIRC
Title: Re: Designing a new Finder
Post by: it0uchpods on December 17, 2016, 04:18:34 PM
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
Title: Re: Designing a new Finder
Post by: OS923 on December 19, 2016, 08:49:06 AM
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.
Title: Re: Designing a new Finder
Post by: DieHard on December 19, 2016, 09:48:03 AM
Quote
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...

:)

Title: Re: Designing a new Finder
Post by: IIO on December 19, 2016, 07:05:23 PM
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?)
Title: Re: Designing a new Finder
Post by: OS923 on December 20, 2016, 06:36:44 AM
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?
Title: Re: Designing a new Finder
Post by: Apfel on December 28, 2016, 02:42:35 PM
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
Quote
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?
Title: Re: Designing a new Finder
Post by: IIO on December 28, 2016, 06:58:31 PM
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)
Title: Re: Designing a new Finder
Post by: IIO on December 28, 2016, 07:04:08 PM
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.

Title: Re: Designing a new Finder
Post by: OS923 on December 29, 2016, 07:17:20 AM
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.
Title: Re: Designing a new Finder
Post by: IIO on December 29, 2016, 10:31:46 AM
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".
Title: Re: Designing a new Finder
Post by: OS923 on March 06, 2017, 06:11:49 AM
I published intermediate problems and solutions on this page:
https://www.gangstalking.eu/problems/index.htm
Title: Re: Designing a new Finder
Post by: OS923 on April 06, 2017, 06:05:45 AM
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.
Title: Re: Designing a new Finder
Post by: OS923 on April 07, 2017, 03:15:42 AM
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?
Title: Re: Designing a new Finder
Post by: nanopico on April 07, 2017, 05:57:16 AM
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?

Personally nothing.  I actually do use the information at the top and it is very useful to me.
What you are suggesting is starting to go away from the actual design of OS 9 and now making an inconsistent environment. The should be no menus there and they all should be in the top with all the rest.

Now having  a folder path would be useful. A better solution would be to put that at the bottom of the window. This should also be a finder preference to turn off.

That is just my view, but what do I know, I've only been dealing with user interface design in software for 15 years.
Title: Re: Designing a new Finder
Post by: IIO on April 12, 2017, 12:47:56 PM


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?

menu for changing view options would be great!

and a menu for changing label colors and  locking/unlocking (all selected files in the window) would also be nice.

buttons... what about a button for "calculate size(s) now" (and another click would disable size calculation again)

a menu for the path... erm... you know that there is a menu for path (via apple-click), do you?

button for going back to the super... personally i use keyboard commands to navigate, it is faster than using a mouse.
Title: Re: Designing a new Finder
Post by: IIO on April 12, 2017, 12:53:47 PM
Quote
What you are suggesting is starting to go away from the actual design of OS 9

i see what you mean. maybe there should not be too much removed and all new features should be at least opt-out - like you said, by disabling certain of the ++ features via finder prefs.
Title: Re: Designing a new Finder
Post by: IIO on April 12, 2017, 12:55:53 PM
one-click stuff/unstuff and zip/unzip would also be fun to have in the window top bar.

eventually it can just be taken from the stuff it menu (which should be apple event i think)
Title: Re: Designing a new Finder
Post by: DieHard on April 23, 2017, 08:29:01 PM
If it fits the name of the current Volume would be great

I am sure the full path would be too long.
Title: Re: Designing a new Finder
Post by: OS923 on May 03, 2017, 05:10:19 AM
Quote
What you are suggesting is starting to go away from the actual design of OS 9

i see what you mean. maybe there should not be too much removed and all new features should be at least opt-out - like you said, by disabling certain of the ++ features via finder prefs.
All features are defined in plugins. You disable a feature by removing the corresponding plugin.
Title: Re: Designing a new Finder
Post by: OS923 on May 03, 2017, 05:12:03 AM
one-click stuff/unstuff and zip/unzip would also be fun to have in the window top bar.

eventually it can just be taken from the stuff it menu (which should be apple event i think)
I would like to do the stuff/unstuff because the archive viewer from StuffIt Deluxe is too slow and uses too much memory, but I can't find the SDK.
Title: Re: Designing a new Finder
Post by: OS923 on May 03, 2017, 05:17:42 AM
If it fits the name of the current Volume would be great

I am sure the full path would be too long.
I won't do the full path. A path in a menu is better. The name of the volume is a good idea, but it's possible to have several volumes with the same name. Another option is to give your volume a label color and then draw the windows of this volume in this color. Another option is to give your volume an icon and then draw the icon in the windows of this volume.
Title: Re: Designing a new Finder
Post by: OS923 on May 03, 2017, 07:05:37 AM
I understand your concern. If you remove all plugins then it should look just like the old Finder.
Title: Re: Designing a new Finder
Post by: DieHard on May 07, 2017, 09:40:19 PM
Quote
Another option is to give your volume a label color and then draw the windows of this volume in this color

That's great, works for me, because I already give each volume a different Color already :)
Title: Re: Designing a new Finder
Post by: WolfpackN64 on May 13, 2017, 05:44:37 AM
What I wonder is if it would be possible in the long run to create a form of snap window functionality in Mac OS 9 and in Finder, like Windows and many Linux distros do (up to snap a window to fullscreen, left for left side half and right for a right side half). It always boggled me Mac OS X (or macOS) never really included this feature (Sierra has it in a way that makes no sense whatsoever).

Maybe as an extension?
Title: Re: Designing a new Finder
Post by: OS923 on May 24, 2017, 06:38:48 AM
There is already such an extension but I didn't try it yet:
http://afturgurluk.org/mirrors/macintosh/archive.info-mac.org/gui/screen-grid-10.hqx
Quote
Abstract of INFO-MAC archived encoded Mac binary file
   'gui/screen-grid-10.hqx'
  Uploaded 08/04/2000   193200 bytes

From: Mamoru Misono <[email protected]>
Subject: ScreenGrid 1.0


ScreenGrid is a desktop-utility that makes operations to
drag and grow windows comfortable. When you drag or grow
a window, ScreenGrid helps you to
 + snap the window to screen edges.
 + snap the window to virtual grid on screens.
 + snap the window to window edges.
 + layout windows with certain offsets.
 + limit the movement of the window horizontally, vertically and 45 degrees.

System Requirement
 PPC or 68K Macintosh
 System 7 or later

ScreenGrid is $7 shareware.
If this isn't what you want, then the DragWindowGrid and DragWindow INIT Apple demos can be combined to such an extension. DragWindow is PPC, I can do 68K eventually.
Title: Re: Designing a new Finder
Post by: WolfpackN64 on May 24, 2017, 06:45:41 AM
Ah, thanks. I haven't found this yet. I'll try it as soon as I can get to my G4 Power Mac again.
Title: Re: Designing a new Finder
Post by: OS923 on May 31, 2017, 04:13:39 AM
There is already such an extension but I didn't try it yet:
http://afturgurluk.org/mirrors/macintosh/archive.info-mac.org/gui/screen-grid-10.hqx
I can't find the right program to decompress that file. It's base64. If I decode it, then I get a file which looks random but characters 59, 187 and 236 are unused. I checked several hqx files on several websites. They have the same problem.
Title: Re: Designing a new Finder
Post by: OS923 on June 01, 2017, 06:35:18 AM
This worked for me: http://www.webutils.pl/BinHex
First copy ftp://ftp.bu.edu/pub/mirrors/info-mac/gui/screen-grid-10.hqx
Then remove everything before
Quote
(This file must be converted with BinHex 4.0)
The documentation says:
Quote
ScreenGrid is distributed as shareware. If you would like to continue using ScreenGrid, please register and support shareware. There is no functional restriction on unregistered copy. However unregistered copy will sometimes ask you to register when starting up. Registration fee for single user license of ScreenGrid is $7(800 yen).
Title: Re: Designing a new Finder
Post by: classicmacreborn7 on January 06, 2019, 06:24:57 PM
I've actually been working on a replacement Finder.  Maybe I should post it in another topic...
Title: Re: Designing a new Finder
Post by: OS923 on March 11, 2019, 08:25:16 AM
I linked PCRE and PCRE2. This will be used to select files. One of the criticisms of the OS 9 Finder is that you can't select files with a regular expression.
Title: Re: Designing a new Finder
Post by: OS923 on March 21, 2019, 06:52:47 AM
This discussion is finished. Go to 9.3 (http://macos9lives.com/smforum/index.php/topic,4880.0.html)
Title: Re: Designing a new Finder
Post by: snes1423 on December 10, 2020, 01:53:22 PM
Hey os923 your websites down and clicking the link leads to Chinese malware  :(
Title: Re: Designing a new Finder
Post by: OS923 on December 12, 2020, 03:43:47 AM
My website had so many files and folders that it was difficult to maintain with FTP.
Title: Re: Designing a new Finder
Post by: OS923 on December 12, 2020, 03:47:31 AM
Taking over the desktop is still unresolved. I see 2 possible solutions:
- Cover the desktop with a window with a special WDEF.
- Install patches in Finder to redirect certain things to my program.
Title: Re: Designing a new Finder
Post by: teroyk on December 13, 2020, 08:51:51 AM
I'm in favor of "Long Unicode Finder" because it describes best what it does.

How about Long Finder.
Mac OS 9.2.2 should support unicode. Look paths from installation CD:
/CD Extras/Language Kit CD Extra/
and
/CD Extras/Unicode/
or is those only in CD what came with Powerbook 667Mhz?
Title: Re: Designing a new Finder
Post by: cc333 on December 15, 2020, 11:01:49 AM
I don't think anyone has suggested SuperFinder yet, so I will :)

Either that, or how about we just call it Finder 9.3 or something simple like that?  Then it can blend in more, kind of like a natural evolution of the original Finder, rather than a rewritten replacement, and thus be more consistent with the rest of the UI as originally designed by Apple.

And, I think having a simple toolbar (and maybe also either a Windows-style "address bar" or OS X-style "path bar") in the style of Windows 95 (but without the on-window menu bar, since the omnipresent one at the top of the screen would render it redundant) slotted between the title bar and status bar would be useful.

Also, better right click support with more consistent and thorough contextual menus would be nice to have.

But, to prevent excessive feature creep, how about concentrating first on completing  relatively doable under-the-hood enhancements first, like faster file copy and better unicode support?

Then, once those core features are stable, more advanced features can be gradually added.  Perhaps in the form of plug-ins or add-ons (as in Firefox and the like)?

c
Title: Re: Designing a new Finder
Post by: OS923 on December 15, 2020, 01:08:18 PM
Hack Finder?
Title: Re: Designing a new Finder
Post by: Hopfenholz on December 16, 2020, 12:55:31 AM
I thought of a good name

9der
Title: Re: Designing a new Finder
Post by: OS923 on December 23, 2020, 04:34:59 AM
I know a bit more. It requires the Display Manager.
Title: Re: Designing a new Finder
Post by: OS923 on December 23, 2020, 04:37:02 AM
What do you think of Finder++ ?

It indicates that it’s better than Finder and that it’s written in C++.
Title: Re: Designing a new Finder
Post by: IIO on December 25, 2020, 03:19:08 AM
or Finder II
Title: Re: Designing a new Finder
Post by: OS923 on December 25, 2020, 07:29:57 AM
The title of Finder's invisible window is "Desktop". Its contRgn and visRgn are equal to desktopRegion. It’s the same handle. strucRgn is 0,0,0,0.

I tried the solution with the special WDEF. I made a window with precisely the same regions as the Finder window. It doesn't crash, but it doesn't actually draw the desktop.
Title: Re: Designing a new Finder
Post by: OS923 on December 26, 2020, 04:58:49 AM
Finder.be

This indicates that it's made in Belgium.
Belgium is supposed to have such big brains
but Belgium doesn't have a single noteworthy software product,
or it would have to be mine.

Space Finder
Deep Finder
Deep Finder 9
Finder into darkness
Blue Finder
Cube Finder
Jackass Finder
Finder for the rest of us
Wonder Finder
Dream Finder
Galactic Finder
Woke Finder
Finder Ascending
Kick-ass Finder
Deadpool Finder
Finder unto dawn
Telltale Finder
Autobahn Finder
Shadow Finder
Fake Finder
Deepfake Finder
Finder double
Ersatz Finder
Wannabe Finder
Finder clone
Top Finder
Ultra Finder
Smart Finder
Unfinder
Express Finder
Alt Finder
Next Generation Finder
Community Finder
Title: Re: Designing a new Finder
Post by: IIO on December 27, 2020, 09:05:19 AM
image line is from belgium. but there it stops. :)
Title: Re: Designing a new Finder
Post by: OS923 on December 29, 2020, 06:06:17 AM
That's not my idea of noteworthy.
Title: Re: Designing a new Finder
Post by: IIO on December 29, 2020, 01:56:01 PM
of course. they did not support mac for a long time, i should have taken that into account. :)
Title: Re: Designing a new Finder
Post by: OS923 on December 31, 2020, 08:37:28 AM
I take into account how many Belgians can name one Belgian software product. We don’t have something like AppleWorks, Photoshop or Firefox, Tor, YouTube or Facebook, nothing. We have mail.be but most people don’t know it.
Title: Re: Designing a new Finder
Post by: IIO on December 31, 2020, 10:30:46 AM
germany... has maxxon, inno/bluebyte/gameforge/funatic/crytek/halyconmedia/sandbox/ubisoft/thq/spellbound, steinberg/emagic/tcworks/NI(except brian), SAP/datev/softwareAG ... i can name them by heart in under a minute.

even the wamcom browser has its seat around the corner from my view.

but belgium... well, has swift. and that is not nothing, it is quite a big club, 7th biggest IT company in europe. https://www.swift.com/
Title: Re: Designing a new Finder
Post by: IIO on December 31, 2020, 10:37:39 AM
and swift is quite important.

they manage and monitor when you transfer money after you bought something which you dont need, to impress people you dont like, from money you dont have.

and they offer two superb extra services with that: 1.) they do not give you a warranty if a transaction fails and 2.) they give all your data to the CIA because we are all terrorists.

plus it is only located in belgium because of their tax policy. :)
Title: Re: Designing a new Finder
Post by: OS923 on January 01, 2021, 05:05:25 AM
... located in Belgium because Belgians want to meddle in everything.
Title: Re: Designing a new Finder
Post by: IIO on January 01, 2021, 08:44:54 AM
dont cry. you still have caramel wafers and newbeat. both is much appreciated.
Title: Re: Designing a new Finder
Post by: OS923 on January 06, 2021, 10:00:12 AM
Good news. I can now draw the desktop just like Finder does. This works as a 68K extension. I’ll write a PPC version and a control panel. In theory I can also claim an area of the desktop, and this may have any shape and doesn’t even have to be contiguous, and leave the rest of the desktop to Finder. In theory I can also divide the desktop among different programs.

There are now 2 mystery problems left: Unicode window titles and colorful window frames.
Title: Re: Designing a new Finder
Post by: IIO on January 06, 2021, 02:38:46 PM
wow great.

color borders? around the original desktop window or what?

there are those rounded corner badges, that i know. i once tried to find them in the suitcase to get rid of them.
Title: Re: Designing a new Finder
Post by: OS923 on January 08, 2021, 01:53:39 PM
I mean the gray window frames.
Title: Re: Designing a new Finder
Post by: OS923 on January 10, 2021, 10:11:04 AM
I chose the solution where I divide the desktop among different programs. I can now create widgets on the desktop. It does only drawing, no clicking, dragging or resizing yet. I'll do that later. With clicking, dragging and resizing it will be possible to have a dock like in OSX.

It continues to work when Finder quits. If Finder is running, then it continues to draw icons on the desktop. You should quit Finder, except if you are developing widgets and you have no Finder replacement.

Widgets have to be applications or appe extensions. Typically you program widgets as appe extensions and the rest of the desktop as an application. You can resort to offscreen drawing to avoid flickering (unlike Finder). Widgets may be stopped in the debugger. This doesn't cause the extension to crash.

This works now as a 68K extension. This is already so fast that you don't notice it, but I'll write a PPC version anyway.

Errors are logged in the "Log" file in the "OS 9.3" folder in the documents folder to make debugging easier.

You need to install the extension and include this library, which is fairly simple:

Code: [Select]
//========================================
// File: Desktop.h
//========================================

#pragma once

class Desktop
{
public:
    // Global functions.
    static Bool Init_class();
    static Bool Claim(OSType creator,
                      RgnHandle claimRgn,
                      UInt32 &ref);
    static Bool ClaimRest(OSType creator,
                          UInt32 &ref);
    static Bool Release(OSType creator);
    static Bool ReleaseRest();
    static Bool Check();
    static Bool CheckPart(UInt32 ref,
                          bool &needsUpdate);
    static Bool BeginUpdate(UInt32 ref);
    static Bool EndUpdate(UInt32 ref);
    static Bool Refresh(UInt32 ref);

    // Forbidden.
private:
    Desktop();
};

claimRgn is the region of the desktop that you would like to have. Sometimes this won't be possible because part of the region is already taken. Then you get what's left over, or nothing. With every claim or release the desktop regions are recalculated.

BeginUpdate and EndUpdate set and restore the right port and clipping and clear the update region.

This will be more complicated when I have done the clicking, dragging and resizing.

The following example is a widget that draws a white ball with a black border:

Code: [Select]
//========================================
// File: Ball.cp
//========================================

#include "Ball.h"

#include "BallApp.h"

int main()
{
    SetDebugThrow_(debugAction_Alert);
    SetDebugSignal_(debugAction_Alert);
    InitializeHeap(3);
    UQDGlobals::InitializeToolbox();
    new LGrowZone(20000);

    GuiError::Init_class();
    #ifdef __DEBUG__
        Error::Show("\pDebug version");
    #endif

    if (!Desktop::Init_class())
        {
        Return_0("\pInit Desktop class fails");
        }

    BallApp app;
    app.Run();

    return 0;
}
Code: [Select]
//========================================
// File: BallApp.h
//========================================

#pragma once

class BallApp : public LApplication
{
private:
    // Derivation.
    typedef LApplication base;

    // Global data.
    static const OSType creator=
    #ifdef __DEBUG__
        'ball'
    #else
        'Ball'
    #endif
    ;

    // Member data.
    Rect m_bounds;
    RgnHandle m_claimRgn;
    UInt32 m_ref;

    // Construction.
public:
    BallApp();

    // Destruction.
    virtual ~BallApp();

    // Forbidden.
private:
    BallApp(const BallApp &original);
    void operator=(const BallApp &original);

    // LApplication.
public:
    virtual void ProcessNextEvent();
protected:
    virtual void Initialize();

    // Manipulators.
private:
    Bool HandleDesktop();
    void Draw();
};
Code: [Select]
//========================================
// File: BallApp.cp
//========================================

#include "BallApp.h"

BallApp::BallApp()
    : m_ref(0)
{
    ::SetRect(&m_bounds,
              100,
              100,
              200,
              200);

    m_claimRgn=::NewRgn();
    ::OpenRgn();
    ::FrameOval(&m_bounds);
    ::CloseRgn(m_claimRgn);
}

BallApp::~BallApp()
{
    if (m_ref)
        {
        if (!Desktop::Release(creator))
            {
            Return("\pRelease fails");
            }
        }

    ::DisposeRgn(m_claimRgn);
}

void BallApp::ProcessNextEvent()
{
    EventRecord macEvent;

    if (IsOnDuty())
        {
        UEventMgr::GetMouseAndModifiers(macEvent);
        AdjustCursor(macEvent);
        }

    SetUpdateCommandStatus(false);

    Boolean gotEvent=::WaitNextEvent(everyEvent,
                                     &macEvent,
                                     mSleepTime,
                                     mMouseRgn);

    if (!HandleDesktop())
        {
        EXIT("\pHandle desktop fails");
        }

    if (LAttachable::ExecuteAttachments(msg_Event,
                                        &macEvent))
        {
        if (gotEvent)
            {
            DispatchEvent(macEvent);
            }
        else
            {
            UseIdleTime(macEvent);
            }
        }

    LPeriodical::DevoteTimeToRepeaters(macEvent);

    if (IsOnDuty() and GetUpdateCommandStatus())
        {
        UpdateMenus();
        }
}

void BallApp::Initialize()
{
    // Rem: m_claimRgn will be copied to system memory,
    // but I keep it around just in case.
    // For example, I might want to claim another area
    // minus this one.

    if (!Desktop::Claim(creator,
                        m_claimRgn,
                        m_ref))
        {
        EXIT("\pClaim fails");
        }
}

Bool BallApp::HandleDesktop()
{
    if (!Desktop::Check())
        {
        Return_false("\pCheck fails");
        }

    bool needsUpdate;
    if (!Desktop::CheckPart(m_ref,
                            needsUpdate))
        {
        Return_false("\pCheck part fails");
        }

    if (!needsUpdate)
        {
        return True;
        }

    if (!Desktop::BeginUpdate(m_ref))
        {
        Return_false("\pBegin update fails");
        }
    Draw();
    if (!Desktop::EndUpdate(m_ref))
        {
        Return_false("\pEnd update fails");
        }

    return True;
}

void BallApp::Draw()
{
    ::RGBForeColor(&Color_Black);
    ::RGBBackColor(&Color_White);
    ::EraseRgn(m_claimRgn);
    ::FrameRgn(m_claimRgn);
}

Now I concentrate on the problem of colored window frames. See in the attachment the sort of windows that I want.
Title: Re: Designing a new Finder
Post by: IIO on January 10, 2021, 02:57:29 PM
once the technical matters work i will happily provide you with a set of schemes using the correct luminance modes and everyrthing what is needed to make them work together and with original platinum.
Title: Re: Designing a new Finder
Post by: OS923 on January 19, 2021, 11:15:26 AM
The PPC version is finished. If you install the 68K extension then you can use 68K widgets. If you install the PPC extension then you can use PPC widgets. You can't mix them.
Title: Re: Designing a new Finder
Post by: OS923 on January 19, 2021, 11:18:07 AM
The colors are wrong. Red and blue are too light and green is much too dark. If I make a screenshot and I watch it on a Windows computer then the colors are correct. How is that possible?
Title: Re: Designing a new Finder
Post by: OS923 on January 21, 2021, 07:27:06 AM
I found it. Problem solved.
Title: Re: Designing a new Finder
Post by: IIO on January 21, 2021, 09:04:46 PM
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.

OSX does this when you perform a huge task such as copying 30,000 files at once. but it is not intented and in extreme cases it goes together with corrupt files or corrupt desktop entries.
Title: Re: Designing a new Finder
Post by: IIO on January 21, 2021, 09:07:10 PM
The colors are wrong. Red and blue are too light and green is much too dark. If I make a screenshot and I watch it on a Windows computer then the colors are correct. How is that possible?

i had exactly the same issue 20 minutes ago in a forum. i think it is releated to the png format. i cropped and saved-in in OS9, then copied across the clipboard in firefox in win10 -> and light green ended up as dark green.
Title: Re: Designing a new Finder
Post by: IIO on January 21, 2021, 09:09:40 PM
haha, is that window drawn onscreen? do you know that "rounded WDEF SDK" where you can have platinum styled oval windows?
Title: Re: Designing a new Finder
Post by: OS923 on January 22, 2021, 01:35:23 PM
It’s not a window. It’s drawn directly on screen, like the desktop picture and the icons.
Title: Re: Designing a new Finder
Post by: gsteemso on May 30, 2021, 04:13:42 PM
It's been probably 15 years or more since I was able to devote much time to "just what, exactly, IS wrong with Apple's Finder?", so I am probably going to miss several important points here. That said, in no particular order:

- A lot of the stock Finder's most annoying usability shortcomings were addressed by the commercial (or was it shareware?) replacement, "Pathfinder". I couldn't afford it when it was current and I lost track of it thereafter, but who knows; it could be a good source of behavioural examples, if nothing else.

- I believe that the stock Finder's "you might tell it to quit, but you can't totally stop it from returning" thing is due in no small part to it being identified during boot as the first program the system is to run. As I recall, the boot process involves five pieces of stored information, processed sequentially: (1) The boot device/partition, (2) the "blessed" folder in the (usually HFS+) volume (filesystem) on that partition, and the names of (3) the System file, of (4) the default application to execute after booting (normally the Finder, but sometimes the Installer or something more exotic), and of (5) the debugger (if any; usually Macsbug, if it is) within that folder.

The name of the OS routine for ending a program, "ExitToShell", hints at the intended use of that program singled out for execution immediately after booting: it's the "outer shell" within which everything else is done, which is why it automatically resurrects whenever nothing else is running. The same thing happens on single-volume installation media for some versions of the system software, when the thing is configured to boot directly into the Installer instead of the Finder (though I only definitively recall experiencing that with OS X install media, so it may not be directly relevant).

- Even though fairly decent OS-level support is present for foreign file systems, Apple's Finder has usually reacted ungracefully to anything that doesn't match its preconceptions. For example (but first, some background):

The old "Macintosh File System" from 1984, which gave an illusion of directories by storing every file name as a full pathname and then illusorily acting like the file really was stored within all of the directories so named, allowed individual pieces of those pathnames to be up to 63 characters long. (In that era, pretty much all system software was written in Pascal on an Apple Lisa; character strings compatible with that system are of fixed length, and begin with a one-byte datum indicating how many of the bytes in it actually contain text. Such a Pascal string sized to hold a 63-byte datum would occupy a conveniently power-of-2 64-byte block.)

When the MFS' replacement, the Heirarchical File System, was being designed only a couple of years later, there was a great need to make each file's metainformation (stored in the volume's "where everything actually _is_" catalogue) as compact as possible so that more than one catalogue entry could be squeezed into a single 512-byte disk block. Reserving a 64-byte Pascal string for the filename would eat a full eighth of a disk block all by itself, and how many people really used names that long? (I can tell you that I rarely even came close, back before I had access to interesting downloadables online; of course, after that particular paradigmatic peregrination, I've used a lot more information in my filenames to clearly identify things.) In any case, halving the space reserved for filenames to 32 bytes (allowing names up to 31 bytes long) seemed a reasonable tradeoff at the time.

Fast forward several Finder iterations, and as of System 7, MFS volumes were sufficiently uncommon that some coder within Apple was unaware of the possibility of a filename ever exceeding the 31-byte HFS maximum; from that point forward -- right up until MFS support was removed entirely! -- if you tried to access an MFS volume containing a filename segment longer than 31 bytes, the Finder would immediately, violently, and messily crash.

Long story short... A hypothetically better Finder's design _must_ allow for arbitrary data it gets from elsewhere to suddenly turn out to be larger in future. As ever, reserving unnecessarily large buffers _now_ would be wasteful and foolish; but planning for some sort of graceful "it might look wrong but it still _works_" near-success mode instead of failing to plan at all and getting a catastrophic failure mode, as Apple once did with the size of filenames, sounds like a smart move to me.
Title: Re: Designing a new Finder
Post by: IIO on May 31, 2021, 12:04:35 AM
A lot of the stock Finder's most annoying usability shortcomings

get some more concrete maybe? :)

Quote
the stock Finder's "you might tell it to quit, but you can't totally stop it from returning" thing is due in no small part to it being identified during boot as the first program the system is to run.

it is a special type of program, not having the usual APPL signature.

there are patches for finder to be able to quit it permanently, but i think you can also quit it using a third party extensions.

Quote
which is why it automatically resurrects whenever nothing else is running.

hmmm. why would one want it not to restart when no other app is open? what can you do with an OS while no application is running?

Quote
Reserving a 64-byte Pascal string for the filename would eat a full eighth of a disk block all by itself, and how many people really used names that long?

i mostly like the finder´s strict character limit a lot. for multimedia work it is great. it forces you to find short and descriptive names, and you end up with a browser with not so wide windows in list view.

however, it begins to suck when you are looking a longer files which originated elsewhere.

a scene release of the type "Grmblfx-GmbH.GermanSuperSoftware.AllInOnePackage.Insert_a_Long_Application_Name_Here.including_cheese_crackers.
mustdownloadnow.Date.Time.Releasegroup.Platform.Version.Build.7z"
will show up as "Grmblfx-GmbH.GermanSuperSof#12345" and then you can not distinguish it from 50 other files and need to use another Browser to be able to read the long name.

but seriously, this is kind of unfixable. while we have beeen discussing to include long names in a new finder, i dont think it is a good idea to let people also write long names in a mac os classic.

dont forget that those long names will only be readable on OS9 machines which also have that new finder, and that many OS9 based file transfer programs will also not be able to transfer those long names.


Quote
the 31-byte HFS maximum

you probably know that but: no! it is only a finder limit. HFS+ allows 255 characters.


Quote
Long story short... A hypothetically better Finder's design _must_ allow for arbitrary data it gets from elsewhere to suddenly turn out to be larger in future.

see above, the transfer protocol must also allow it in order to work.

i believe "show long names" belonged best into the individual view options for the finder windows. :)

Title: Re: Designing a new Finder
Post by: OS923 on May 31, 2021, 08:43:50 AM
That’s right. There should be a feature that you can enable to display long Unicode filenames to give you the chance to replace them with short filenames that don’t cause trouble with other programs. There should be no feature that inserts new long Unicode filenames that no one can handle.

As far as I know, long Unicode filenames are supported by only Finder and StuffIt, and even they can’t display them.

Worst of all is that if you have a long Unicode filename, then it is shortened with a hexadecimal number at the end which changes if you move the file to another folder.
Title: Re: Designing a new Finder
Post by: Mat on May 31, 2021, 10:43:22 AM
dont forget that those long names will only be readable on OS9 machines which also have that new finder,
And as so often I do not get why we are discussing things that can be done/used since the 90ies. You know about "Joliet Volume Access" and "Kilometre Browser" ( https://www.faustic.com/km/old.html )?

I for myselve think that 31 characters are fine. Everything more than 64 characters is for sure not useful for a name (!) that should identyfy a file inside a GUI. Even modern Linux-Desktops are restricting visible characters to 50 per file. So longer filenames are an explenation and would belong to comments, or a readmefile or be presented by a folder structure, but not by extending a name! That ugly behaviour to make huge file names at other operating systems is a workaround for what filenames never have been intended!  Mac OS 9 is clear, straight and consistent regarding this field, and I still love it for being so.
Title: Re: Designing a new Finder
Post by: IIO on May 31, 2021, 01:35:41 PM
it has not been useful in the past to call your audiofiles
SoundOfAPianoFallingDownTheStairsVersion3Revision2StereoMastered.aif
and then tell your friends or customers "if you want to see the name, please use a third party browser" - and it wont be very useful in 2021 either.

to be exact, even in operating systems like 10.14 or windows 10 where you can have thousands of characters, i much appreciate short names. :)
Title: Re: Designing a new Finder
Post by: Mat on May 31, 2021, 03:06:29 PM
Exactly!
And what I wanted to say with my posting above is that it doesn't matter if it is a tool that we have for 25 years, or a system extention that makes long filenames available.
Title: Re: Designing a new Finder
Post by: IIO on May 31, 2021, 03:58:56 PM
that is the point where we disagree.

while both is a third party tool which you only need to read long names, it would be really nice to have it integrated into the / a finder.

coela, kilometre and the long info CMM are not ideal to use.
Title: Re: Designing a new Finder
Post by: OS923 on June 05, 2021, 06:42:20 AM
I looked into those softwares with The Fragmalyzer. They don’t use Textension. They can’t edit Unicode.

Then I looked into CW Pro 8 how much trouble it would be to edit Unicode. I found it easy. The clipboard works with Unicode.

I think about a program that opens a window for every dropped item. It shows the long Unicode name in the text and the normal name in the title. You can change the name and then Save and this updates the name. Just a small program that does one thing. This would be only a few lines of code and I make it open source. Then you can adapt it to your own taste.
Title: Re: Designing a new Finder
Post by: IIO on June 05, 2021, 08:49:58 AM
this is how "long info" looks.

it only processes single files and wont even open when you select two items.

Title: Re: Designing a new Finder
Post by: OS923 on June 08, 2021, 10:54:22 AM
I adapted CW Pro 8.3’s LMLTEPane to make it work with CW Pro 6.3. I can now edit long filenames. Drag items to the program and it opens a window for every item. If you change something in Finder then the window is updated.

Unicode doesn’t work yet. It was more complicated than I anticipated.

These are the available text encodings:
Code: [Select]
Text encoding 0: base=0 variant=1 format=0
Text encoding 1: base=0 variant=2 format=0
Text encoding 2: base=1 variant=0 format=0
Text encoding 3: base=1 variant=1 format=0
Text encoding 4: base=1 variant=2 format=0
Text encoding 5: base=1 variant=3 format=0
Text encoding 6: base=1 variant=4 format=0
Text encoding 7: base=1 variant=5 format=0
Text encoding 8: base=2 variant=0 format=0
Text encoding 9: base=3 variant=0 format=0
Text encoding 10: base=4 variant=0 format=0
Text encoding 11: base=4 variant=1 format=0
Text encoding 12: base=4 variant=2 format=0
Text encoding 13: base=4 variant=3 format=0
Text encoding 14: base=5 variant=0 format=0
Text encoding 15: base=5 variant=1 format=0
Text encoding 16: base=6 variant=0 format=0
Text encoding 17: base=7 variant=1 format=0
Text encoding 18: base=7 variant=2 format=0
Text encoding 19: base=7 variant=3 format=0
Text encoding 20: base=9 variant=0 format=0
Text encoding 21: base=10 variant=0 format=0
Text encoding 22: base=11 variant=0 format=0
Text encoding 23: base=21 variant=0 format=0
Text encoding 24: base=25 variant=0 format=0
Text encoding 25: base=26 variant=0 format=0
Text encoding 26: base=29 variant=0 format=0
Text encoding 27: base=33 variant=0 format=0
Text encoding 28: base=34 variant=0 format=0
Text encoding 29: base=35 variant=0 format=0
Text encoding 30: base=36 variant=1 format=0
Text encoding 31: base=36 variant=2 format=0
Text encoding 32: base=37 variant=2 format=0
Text encoding 33: base=37 variant=3 format=0
Text encoding 34: base=37 variant=4 format=0
Text encoding 35: base=37 variant=5 format=0
Text encoding 36: base=38 variant=1 format=0
Text encoding 37: base=38 variant=2 format=0
Text encoding 38: base=41 variant=0 format=0
Text encoding 39: base=140 variant=0 format=0
Text encoding 40: base=140 variant=1 format=0
Text encoding 41: base=252 variant=1 format=0
Text encoding 42: base=252 variant=2 format=0
Text encoding 43: base=257 variant=0 format=0
Text encoding 44: base=257 variant=0 format=1
Text encoding 45: base=257 variant=0 format=2
Text encoding 46: base=259 variant=0 format=0
Text encoding 47: base=259 variant=0 format=1
Text encoding 48: base=259 variant=0 format=2
Text encoding 49: base=259 variant=2 format=0
Text encoding 50: base=260 variant=0 format=0
Text encoding 51: base=260 variant=0 format=1
Text encoding 52: base=260 variant=0 format=2
Text encoding 53: base=260 variant=2 format=0
Text encoding 54: base=513 variant=0 format=0
Text encoding 55: base=514 variant=0 format=0
Text encoding 56: base=515 variant=0 format=0
Text encoding 57: base=516 variant=0 format=0
Text encoding 58: base=517 variant=0 format=0
Text encoding 59: base=518 variant=0 format=0
Text encoding 60: base=519 variant=0 format=0
Text encoding 61: base=520 variant=0 format=0
Text encoding 62: base=521 variant=0 format=0
Text encoding 63: base=527 variant=0 format=0
Text encoding 64: base=1024 variant=0 format=0
Text encoding 65: base=1040 variant=0 format=0
Text encoding 66: base=1049 variant=0 format=0
Text encoding 67: base=1053 variant=0 format=0
Text encoding 68: base=1056 variant=0 format=0
Text encoding 69: base=1057 variant=0 format=0
Text encoding 70: base=1059 variant=0 format=0
Text encoding 71: base=1280 variant=0 format=0
Text encoding 72: base=1281 variant=0 format=0
Text encoding 73: base=1282 variant=0 format=0
Text encoding 74: base=1283 variant=0 format=0
Text encoding 75: base=1284 variant=0 format=0
Text encoding 76: base=1285 variant=0 format=0
Text encoding 77: base=1286 variant=0 format=0
Text encoding 78: base=1287 variant=0 format=0
Text encoding 79: base=1288 variant=0 format=0
Text encoding 80: base=1536 variant=0 format=0
Text encoding 81: base=1570 variant=0 format=0
Text encoding 82: base=1584 variant=0 format=0
Text encoding 83: base=1585 variant=0 format=0
Text encoding 84: base=1600 variant=0 format=0
Text encoding 85: base=2080 variant=0 format=0
Text encoding 86: base=2096 variant=0 format=0
Text encoding 87: base=2112 variant=0 format=0
Text encoding 88: base=2336 variant=0 format=0
Text encoding 89: base=2352 variant=0 format=0
Text encoding 90: base=2353 variant=0 format=0
Text encoding 91: base=2368 variant=0 format=0
Text encoding 92: base=2561 variant=0 format=0
Text encoding 93: base=2562 variant=0 format=0
Text encoding 94: base=2563 variant=0 format=0
Text encoding 95: base=2564 variant=2 format=0
Text encoding 96: base=2564 variant=6 format=0
Text encoding 97: base=2564 variant=11 format=0
Text encoding 98: base=2564 variant=14 format=0
Text encoding 99: base=2565 variant=0 format=0
Text encoding 100: base=2817 variant=0 format=0
Text encoding 101: base=3074 variant=0 format=0
Text encoding 102: base=4095 variant=0 format=0

These are the available Unicode conversions:
Code: [Select]
Text encoding 43 -> 44
Text encoding 44 -> 43
Text encoding 43 -> 45
Text encoding 45 -> 43
Text encoding 46 -> 47
Text encoding 47 -> 46
Text encoding 46 -> 48
Text encoding 48 -> 46
Text encoding 46 -> 49
Text encoding 48 -> 49

HFS+ filenames are Unicode 2.0 canonical decomp variant (I call this HFS). Classic Mac OS can convert Unicode 2.0 16-bit (46) and Unicode 2.0 UTF8 (48) to HFS (49) but not the other way. Once it's converted to HFS it can't be converted to anything. Linking to Carbon didn't make a difference. Note also that it can't convert between Unicode 1.1 (257) and Unicode 2.0 (259). Thus I have to write my own conversion.

A table-based solution would take 595*65536*sizeof(Element) of memory. That may be the reason why Apple didn’t include this in the MacOS. Thus I'll use a tree-based solution.

I tried this first in Scheme and it works.
Code: [Select]
(require-library "compat.ss")

(load "Data1.ss")
(load "Data2.ss")
(load "Data3.ss")
(load "Data4.ss")

(define conversie
  (class object% ()
    (private
      [boom '()]
      [unicode #f])
    (public
      [voegtoe (lambda (x lijst)
                 (if (null? lijst)
                     (set! unicode x)
                     (letrec ((eerste (car lijst))
                              (rest (cdr lijst))
                              (gevonden (assoc eerste boom)))
                       (if gevonden
                           (send (cadr gevonden) voegtoe x rest)
                           (let ((nieuw (make-object conversie)))
                             (begin
                               (set! boom (cons (list eerste nieuw) boom))
                               (send nieuw voegtoe x rest)))))))]
      [zoek (lambda (lijst)
              (if (null? lijst)
                  unicode
                  (letrec ((eerste (car lijst))
                           (rest (cdr lijst))
                           (gevonden (assoc eerste boom)))
                    (if gevonden
                        (send (cadr gevonden) zoek rest)
                        #f))))]
      [tel (lambda ()
             (define (som boom)
               (if (null? boom)
                   0
                   (let ((eerste (car boom))
                         (rest (cdr boom)))
                     (+ (send (cadr eerste) tel)
                        (som rest)))))
             (if (null? boom)
                 0
                 (+ 1 (som boom))))]
      [sorteer (lambda ()
                 (define (kleinerdan? x y)
                   (< (car x) (car y)))
                 (if (null? boom)
                     'ok
                     (set! boom (sort kleinerdan? boom))))]
      [schrijf (lambda ()
                 (define (vertaal paar)
                   (list (car paar) (send (cadr paar) schrijf)))
                 (if (null? boom)
                     (number->string unicode)
                     (map vertaal boom)))])
    (sequence
      (super-init))))

(define c (make-object conversie))
(define (voegtoe x lijst) (send c voegtoe x lijst))
(define (zoek lijst) (send c zoek lijst))
(define (tel) (send c tel))
(define (sorteer) (send c sorteer))
(define (schrijf) (send c schrijf))

(define (voegdatatoe data)
  (define (voeg-x-en-lijst-toe r)
    (voegtoe (car r) (cdr r)))
  (for-each voeg-x-en-lijst-toe data))

(voegdatatoe data1)
(voegdatatoe data2)
(voegdatatoe data3)
(voegdatatoe data4)

(zoek '(180)) ; -> 8189
(zoek '(105 769)) ; -> 146
(zoek '(4362 4468 4532)) ; -> 50457
(zoek '(919 837 788 769)) ; -> 8093

(tel) ; -> 595

(sorteer)

(schrijf)

Now I have to write the C++ version. Then I can EDIT Unicode filenames.
Title: Re: Designing a new Finder
Post by: OS923 on June 13, 2021, 09:40:07 AM
Almost right. Not bad for a first try.

First you need to make a text encoding converter.
Code: [Select]
Bool BOOL_MakeTables()
{
    TextEncoding const plainTextEncoding=
        ::CreateTextEncoding(kTextEncodingUnicodeV2_0,
                             kUnicodeNoSubset,
                             kUnicode16BitFormat);
    if (!plainTextEncoding)
        {
        ReturnFalse("\pCreateTextEncoding fails");
        }

    TextEncoding const hfsTextEncoding=
        ::CreateTextEncoding(kTextEncodingUnicodeV2_0,
                             kUnicodeCanonicalDecompVariant,
                             kUnicode16BitFormat);
    if (!hfsTextEncoding)
        {
        ReturnFalse("\pCreateTextEncoding fails");
        }

    TECObjectRef plainToHFS;
    OSStatus status=::TECCreateConverter(&plainToHFS,
                                         plainTextEncoding,
                                         hfsTextEncoding);
    if (status)
        {
        ReturnFalse_status("\pTECCreateConverter fails",status);
        }

    const Bool ok=BOOL_MakeTables(plainToHFS);

    status=::TECDisposeConverter(plainToHFS);
    if (status)
        {
        ReturnFalse("\pTECDisposeConverter fails");
        }

    if (!ok)
        {
        ReturnFalse("\pMakeTables fails");
        }

    return True;
}

Then you need to make 4 tables.
Code: [Select]
#include "Make4Tables.h"

#include "PStr.cp.h"

//----------------------------------------
// Implementation details.
//----------------------------------------

Bool BOOL_MakeTable(TECObjectRef plainToHFS,
                    SInt32 length);

Bool BOOL_MakeTable(TECObjectRef plainToHFS,
                    SInt32 length,
                    BigTextFileWriter &cpp);

Bool BOOL_MakeTable(TECObjectRef plainToHFS,
                    SInt32 length,
                    BigTextFileWriter &cpp,
                    BigTextFileWriter &scheme);

Bool BOOL_ShowCpp(UniChar plain,
                  const HFSUniStr255 &u,
                  BigTextFileWriter &cpp);

Bool BOOL_ShowScheme(UniChar plain,
                     const HFSUniStr255 &u,
                     BigTextFileWriter &scheme);

//----------------------------------------

Bool BOOL_Make4Tables(TECObjectRef const plainToHFS)
{
    for (SInt32 length=1;length<=4;length++)
        {
        if (!BOOL_MakeTable(plainToHFS,
                            length))
            {
            ReturnFalse("\pMakeTable fails");
            }
        }
    return True;
}

//----------------------------------------
// Implementation details.
//----------------------------------------

Bool BOOL_MakeTable(TECObjectRef const plainToHFS,
                    const SInt32 length)
{
    PStr<31> path;
    SpellReadable(path,"\p:Output:Data");
    SpellNumber(path,length);
    SpellReadable(path,"\p.cp");

    FSSpec spec;
    OSErr err=::FSMakeFSSpec(0,
                             0,
                             path,
                             &spec);
    if (err)
        {
        if (err!=fnfErr)
            {
            ReturnFalse_err("\pFSpCreate fails",err);
            }
        err=::FSpCreate(&spec,
                        'R*ch',
                        'TEXT',
                        smSystemScript);
        if (err)
            {
            ReturnFalse_err("\pFSpCreate fails",err);
            }
        }

    BigMacFileWriter cpp;
    if (!cpp.BOOL_Open(spec))
        {
        ReturnFalse("\pOpen fails");
        }

    const Bool ok=BOOL_MakeTable(plainToHFS,
                                 length,
                                 cpp);

    if (!cpp.BOOL_Close())
        {
        ReturnFalse("\pClose fails");
        }

    if (!ok)
        {
        ReturnFalse("\pMakeTable fails");
        }

    return True;
}

Bool BOOL_MakeTable(TECObjectRef const plainToHFS,
                    const SInt32 length,
                    BigTextFileWriter &cpp)
{
    PStr<31> path;
    SpellReadable(path,"\p:Output:Data");
    SpellNumber(path,length);
    SpellReadable(path,"\p.ss");

    FSSpec spec;
    OSErr err=::FSMakeFSSpec(0,
                             0,
                             path,
                             &spec);
    if (err)
        {
        if (err!=fnfErr)
            {
            ReturnFalse_err("\pFSpCreate fails",err);
            }
        err=::FSpCreate(&spec,
                        'R*ch',
                        'TEXT',
                        smSystemScript);
        if (err)
            {
            ReturnFalse_err("\pFSpCreate fails",err);
            }
        }

    BigMacFileWriter scheme;
    if (!scheme.BOOL_Open(spec))
        {
        ReturnFalse("\pOpen fails");
        }

    const Bool ok=BOOL_MakeTable(plainToHFS,
                                 length,
                                 cpp,
                                 scheme);

    if (!scheme.BOOL_Close())
        {
        ReturnFalse("\pClose fails");
        }

    if (!ok)
        {
        ReturnFalse("\pMakeTable fails");
        }

    return True;
}

Bool BOOL_MakeTable(TECObjectRef const plainToHFS,
                    const SInt32 length,
                    BigTextFileWriter &cpp,
                    BigTextFileWriter &scheme)
{
    SInt32 count=0;
    for (SInt32 i=0;i<65536;i++)
        {
        const UniChar plain=static_cast<UniChar>(i);
        HFSUniStr255 hfs;
        ByteCount actualInputLength;
        ByteCount actualOutputLength;
        const OSStatus status=::TECConvertText(plainToHFS,
                                               reinterpret_cast<ConstTextPtr>(&plain),
                                               2,
                                               &actualInputLength,
                                               reinterpret_cast<TextPtr>(hfs.unicode),
                                               510,
                                               &actualOutputLength);
        if (status)
            {
            ReturnFalse_status("\pTECConvertText fails",status);
            }

        hfs.length=static_cast<UInt16>(actualOutputLength>>1);

        if (hfs.length==length)
            {
            if (not ((length==1) and (*hfs.unicode==plain)))
                {
                count++;
                if (!BOOL_ShowCpp(plain,
                                  hfs,
                                  cpp))
                    {
                    ReturnFalse("\pShowCpp fails");
                    }
                if (!BOOL_ShowScheme(plain,
                                     hfs,
                                     scheme))
                    {
                    ReturnFalse("\pShowScheme fails");
                    }
                }
            }
        }

    cout << "Count for length ";
    cout << length;
    cout << " is ";
    cout << count;
    cout << ".";
    cout << endl;

    return True;
}

Bool BOOL_ShowCpp(const UniChar plain,
                  const HFSUniStr255 &hfs,
                  BigTextFileWriter &cpp)
{
    SpellReadable(cpp,"\p{");
    SpellNumber(cpp,plain);
    for (SInt32 i=0;i<hfs.length;i++)
        {
        SpellReadable(cpp,"\p,");
        SpellNumber(cpp,hfs.unicode[i]);
        }
    SpellReadable(cpp,"\p},");
    StartANewLine(cpp);
    return True;
}

Bool BOOL_ShowScheme(const UniChar plain,
                     const HFSUniStr255 &hfs,
                     BigTextFileWriter &scheme)
{
    SpellReadable(scheme,"\p(");
    SpellNumber(scheme,plain);
    for (SInt32 i=0;i<hfs.length;i++)
        {
        SpellReadable(scheme,"\p ");
        SpellNumber(scheme,hfs.unicode[i]);
        }
    SpellReadable(scheme,"\p)");
    StartANewLine(scheme);
    return True;
}

You can use this to write your own Unicode to HFS conversion.

Then you can use these tables to build a tree. Thanks to the Scheme language we can do this in a few words.
Code: [Select]
(require-library "compat.ss")

(define conversion
  (class object% ()
    (private
      [tree '()]
      [unicode #f])
    (public
      [add (lambda (plain hfs)
             (if (null? hfs)
                 (set! unicode plain)
                 (letrec ((first (car hfs))
                          (rest (cdr hfs))
                          (found (assv first tree)))
                   (if found
                       (send (cadr found) add plain rest)
                       (let ((new (make-object conversion)))
                         (begin
                           (set! tree (cons (list first new) tree))
                           (send new add plain rest)))))))]
      [search (lambda (hfs)
                (if (null? hfs)
                    unicode
                    (letrec ((first (car hfs))
                             (rest (cdr hfs))
                             (found (assoc first tree)))
                      (if found
                          (send (cadr found) search rest)
                          #f))))]
      [count (lambda ()
               (define (sum tree)
                 (if (null? tree)
                     0
                     (let ((first (car tree))
                           (rest (cdr tree)))
                       (+ (send (cadr first) count)
                          (sum rest)))))
               (if (null? tree)
                   0
                   (+ 1 (sum tree))))]
      [merge-sort (lambda ()
                    (define (merge-sort-tree tree)
                      (define (merge-sort-sub x)
                        (send (cadr x) merge-sort))
                      (define (lt? x y)
                        (< (car x) (car y)))
                      (begin
                        (for-each merge-sort-sub tree)
                        (sort lt? tree)))
                    (if (null? tree)
                        'ok
                        (set! tree (merge-sort-tree tree))))]
      [get-tree (lambda ()
                  (define (translate pair)
                    (list (car pair) (send (cadr pair) get-tree)))
                  (if (null? tree)
                      (number->string unicode)
                      (let ((translated (map translate tree)))
                        (if unicode
                            (cons (number->string unicode) translated)
                            translated))))]
      [display-tree-lengths (lambda ()
                              (define (translate pair)
                                (send (cadr pair) display-tree-lengths))
                              (if (not (null? tree))
                                  (begin
                                    (display (length tree))
                                    (newline)
                                    (for-each translate tree))))])
    (sequence
      (super-init))))

(define c (make-object conversion))
(define (add plain hfs) (send c add plain hfs))
(define (search hfs) (send c search hfs))
(define (count) (send c count))
(define (merge-sort) (send c merge-sort))
(define (get-tree) (send c get-tree))
(define (display-tree-lengths) (send c display-tree-lengths))

(define (add-data data)
  (define (add-plain-and-hfs r)
    (add (car r) (cdr r)))
  (for-each add-plain-and-hfs data))

(define (write-binary vpad b)
  (define dest-port
    (open-output-file vpad 'truncate/replace))
  (define (write-n1 n)
    (write-char (integer->char n) dest-port))
  (define (write-n2 n)
    (define hi (quotient n 256))
    (define lo (remainder n 256))
    (write-n1 hi)
    (write-n1 lo))
  (define (write-elements t)
    (begin
      (write-n2 (length t))
      (for-each write-conversion t)))
  (define (write-table t)
    (define first (car t))
    (define rest (cdr t))
    (if (string? first)
        (begin
          (write-n1 0)
          (write-n2 (string->number first))
          (write-elements rest))
        (begin
          (write-n1 1)
          (write-elements t))))
  (define (write-conversion c)
    (define hfs (car c))
    (define x (cadr c))
    (begin
      (write-n2 hfs)
      (if (string? x)
          (begin
            (write-n1 0)
            (write-n2 (string->number x)))
          (begin
            (write-n1 1)
            (write-table x)))))
  (begin
    (for-each write-conversion b)
    (close-output-port dest-port)))

(define (write-scheme vpad x)
  (define dest-port
    (open-output-file vpad 'truncate/replace))
  (begin
    (write x dest-port)
    (close-output-port dest-port)))

(load "Data1.ss")
(load "Data2.ss")
(load "Data3.ss")
(load "Data4.ss")

(add-data data1)
(add-data data2)
(add-data data3)
(add-data data4)

(search '(180)) ; => 8189
(search '(105 769)) ; => 146
(search '(4362 4468 4532)) ; => 50457
(search '(919 837 788 769)) ; => 8093

(count) ; => 595

(merge-sort)

(define b (get-tree))

(write-binary "Tree.dat" b)

(write-scheme "Tree.ss" b)

(display-tree-lengths)
; =>
; root has length 76
; 51 times length 1
; 24 times length 2
; 42 times length 3
; 15 times length 4
; 6 times length 5
; 4 times length 7
; 4 times length 9
; 19 times length 21
; 399 times length 27

The result is saved to a binary file that we copy into 'HFS+' resource 129.

Then you also make a table that tells you wether a character translates into itself:
Code: [Select]
#include "MakeIdentityTable.h"

//----------------------------------------
// Implementation details.
//----------------------------------------

Bool BOOL_MakeIdentityTable(TECObjectRef plainToHFS,
                            BigBinaryFileWriter &output);

//----------------------------------------

Bool BOOL_MakeIdentityTable(TECObjectRef const plainToHFS)
{
    FSSpec spec;
    OSErr err=::FSMakeFSSpec(0,
                             0,
                             "\p:Output:Identity.dat",
                             &spec);
    if (err)
        {
        if (err!=fnfErr)
            {
            ReturnFalse_err("\pFSpCreate fails",err);
            }
        err=::FSpCreate(&spec,
                        'hDmp',
                        'BINA',
                        smSystemScript);
        if (err)
            {
            ReturnFalse_err("\pFSpCreate fails",err);
            }
        }

    BigBinaryFileWriter output;
    if (!output.BOOL_Open(spec))
        {
        ReturnFalse("\pOpen fails");
        }

    const Bool ok=BOOL_MakeIdentityTable(plainToHFS,
                                         output);

    if (!output.BOOL_Close())
        {
        ReturnFalse("\pClose fails");
        }

    if (!ok)
        {
        ReturnFalse("\pMakeIdentityTable fails");
        }

    return True;
}

//----------------------------------------
// Implementation details.
//----------------------------------------

Bool BOOL_MakeIdentityTable(TECObjectRef const plainToHFS,
                            BigBinaryFileWriter &output)
{
    for (SInt32 i=0;i<65536;i++)
        {
        const UniChar plain=static_cast<UniChar>(i);
        HFSUniStr255 hfs;
        ByteCount actualInputLength;
        ByteCount actualOutputLength;
        const OSStatus status=::TECConvertText(plainToHFS,
                                               reinterpret_cast<ConstTextPtr>(&plain),
                                               2,
                                               &actualInputLength,
                                               reinterpret_cast<TextPtr>(hfs.unicode),
                                               510,
                                               &actualOutputLength);
        if (status)
            {
            ReturnFalse_status("\pTECConvertText fails",status);
            }

        hfs.length=static_cast<UInt16>(actualOutputLength>>1);

        const bool identity=(hfs.length==1) and (*hfs.unicode==plain);
        WriteBinary(output,identity);
        }
    return True;
}

The result is saved to a binary file that we copy into 'HFS+' resource 128.

'HFS+' resource 128 is used by the conversions in either direction.
'HFS+' resource 129 is used only by the HFS to Unicode conversion.
The 4 tables are used only by the Unicode to HFS conversion.

Then we notice that there are a few characters which are converted to the same character. If you convert them back then you may not get the original. For example 63, 65534 and 65535 are converted to 63.

Then you may end up with these conversions:
Code: [Select]
59 => 59 => 894
63 => 63 => 65535
96 => 96 => 8175
180 => 180 => 8189
183 => 183 => 903
198 => 198 => 1236
230 => 230 => 1237
399 => 399 => 1240
415 => 415 => 1256
439 => 439 => 1248
601 => 601 => 1241
629 => 629 => 1257
658 => 658 => 1249
697 => 697 => 884
768 => 768 => 832
769 => 769 => 833
787 => 787 => 835
953 => 953 => 8126
65534 => 63 => 65535

We avoid this by storing only the smallest number if there's more than one possibility. Then you get these conversions:
Code: [Select]
832 => 768 => 768
833 => 769 => 769
835 => 787 => 787
884 => 697 => 697
894 => 59 => 59
903 => 183 => 183
1236 => 198 => 198
1237 => 230 => 230
1240 => 399 => 399
1241 => 601 => 601
1248 => 439 => 439
1249 => 658 => 658
1256 => 415 => 415
1257 => 629 => 629
8126 => 953 => 953
8175 => 96 => 96
8189 => 180 => 180
65534 => 63 => 63
65535 => 63 => 63

This was found with this program:
Code: [Select]
Bool BOOL_Test_Unicode_HFS()
{
    for (z4 i=0;i<65536;i++)
        {
        c_n2 unicode1=static_cast<n2>(i);
        z4 hfs_length;
        n2 hfs[4];
        UnicodeToHFS::Convert(unicode1,
                              hfs_length,
                              hfs);
        z4 hfs_used;
        n2 unicode2;
        if (!HFSToUnicode::CanConvert(hfs_length,
                                      hfs,
                                      hfs_used,
                                      unicode2))
            {
            SpellReadable(cout,"\pThere's no conversion for ");
            SpellNumber(cout,unicode1);
            StartANewLine(cout);
            }
        if (hfs_used!=hfs_length)
            {
            ReturnFalse("\pUnused characters");
            }
        if (unicode2!=unicode1)
            {
            SpellNumber(cout,unicode1);
            SpellReadable(cout,"\p => ");
            for (z4 j=0;j<hfs_length;j++)
                {
                SpellNumber(cout,hfs[j]);
                SpellReadable(cout,"\p ");
                }
            SpellReadable(cout,"\p=> ");
            SpellNumber(cout,unicode2);
            StartANewLine(cout);
            }
        }
    return True;
}

My converter reads these resources and recreates the tables and the tree, then disposes the resources.

The memory use is fair:
- around 93 K shared.
- around 640 K for Unicode to HFS only.
- around 527 K for HFS to Unicode only.

Now the bad news: 18134 Unicode characters are not accepted by FSRenameUnicode. That's 28%.
Code: [Select]
Bool BOOL_TryEveryHFSFilenameWithLength1()
{
    FSSpec spec;
    OSErr err=::FSMakeFSSpec(0,
                             0,
                             "\pTest:0",
                             &spec);
    if (err)
        {
        ReturnFalse_err("\pFSMakeFSSpec fails",err);
        }

    FSRef ref;
    err=::FSpMakeFSRef(&spec,
                       &ref);
    if (err)
        {
        ReturnFalse_err("\pFSpMakeFSRef fails",err);
        }

    for (SInt32 i=0;i<65536;i++)
        {
        UniChar unicode[1];
        *unicode=static_cast<UniChar>(i);
        HFSUniStr255 hfs;
        UnicodeToHFS::Convert(1,
                              unicode,
                              hfs);
        err=::FSRenameUnicode(&ref,
                              hfs.length,
                              hfs.unicode,
                              kTextEncodingDefaultFormat,
                              nil);
        if (err)
            {
            cout << "Rename as ";
            cout << i;
            cout << " returns ";
            cout << err;
            cout << '.';
            cout << endl;
            }
        }

    return True;
}

In UnicodeTable.sitx you can see which characters you can use.

That's how far I've got.

See the demo program in the attachment.
Title: Re: Designing a new Finder
Post by: OS923 on July 13, 2021, 07:23:08 AM
 UnicodeNameEditor is discontinued because I don’t use PowerPlant anymore.
Title: Re: Designing a new Finder
Post by: OS923 on August 09, 2021, 10:26:16 AM
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
There’s no need to rewrite the entire WDEF because Appearance allows you to patch the function that draws the title. I tried this today and it works, it draws the title in Geneva 12. This works only with Appearance 1.1. Instead of trying this in a WDEF you can try this in a normal program by drawing a window frame in a window using DrawThemeWindowFrame.
Title: Re: Designing a new Finder
Post by: OS923 on August 23, 2021, 08:33:11 AM
I found the solution for the Unicode window titles.
Title: Re: Designing a new Finder
Post by: OS923 on August 31, 2021, 08:17:06 AM
I found the solution for color windows. This requires ColorSync. It's not flawless. There's a small chance for a glitch in drawing the grow box. I could understand that it's always wrong or usually wrong but not that it's rarely wrong. It’s impossible to debug.
Title: Re: Designing a new Finder
Post by: IIO on August 31, 2021, 10:38:14 AM
it somehow feels "wrong", indeed. but it is great to follow what is possible and why, we can only learn from it.
Title: Re: Designing a new Finder
Post by: OS923 on September 06, 2021, 09:00:34 AM
I found it. The color was stored in an unlocked handle.
Title: Re: Designing a new Finder
Post by: nilobject on December 07, 2021, 11:08:45 PM
i'd like a contextual menu item called "Show Resource Contents", ala "Show Package Contents". Selecting the item would show a Finder style view of the files resource fork.
how is the Finder replacement being developed? prototyped?
thanks
Title: Re: Designing a new Finder
Post by: OS923 on December 11, 2021, 07:42:59 AM
I should write a library for this, then everyone can use this in his own software:

Code: [Select]
Part 1: catalog info.

Button view:

frView 8 = 1
frOpenChain = 11000001000000000000000000000000

large icons =       (frView 3-0 = 0111) and (frFlags 9-5 = 11111) and (frScript 6-3 = 0100)
small icons =       (frView 3-0 = 0111) and (frFlags 9-5 = 11111) and (frScript 6-3 = 1111)

arranged by crDat = (frView 3-0 = 1010) and (frFlags 9-5 = 01010) and (frScript 6-3 = 1100)
arranged by kind =  (frView 3-0 = 1100) and (frFlags 9-5 = 01100) and (frScript 6-3 = 1100)
arranged by label = (frView 3-0 = 1101) and (frFlags 9-5 = 01101) and (frScript 6-3 = 1100)
arranged by mdDat = (frView 3-0 = 1001) and (frFlags 9-5 = 01001) and (frScript 6-3 = 1100)
arranged by name =  (frView 3-0 = 1000) and (frFlags 9-5 = 01000) and (frScript 6-3 = 1100)
arranged by size =  (frView 3-0 = 1011) and (frFlags 9-5 = 01011) and (frScript 6-3 = 1100)
snap to grid =      (frView 3-0 = 1110) and (frFlags 9-5 = 01110) and (frScript 6-3 = 1100)
========================================
Icon view:

frView 8 = 1
frFlags = 0000001111100000
frOpenChain = 11000001000000000000000000000000

large icons =       (frView 3-0 = 0111) and (frScript 6-4 = 000)
small icons =       (frView 3-0 = 0111) and (frScript 6-4 = 101) and (frView 6 = 1)

arranged by crDat = (frView 3-0 = 1010) and (frScript 6-4 = 100)
arranged by kind =  (frView 3-0 = 1100) and (frScript 6-4 = 100)
arranged by label = (frView 3-0 = 1101) and (frScript 6-4 = 100)
arranged by mdDat = (frView 3-0 = 1001) and (frScript 6-4 = 100)
arranged by name =  (frView 3-0 = 1000) and (frScript 6-4 = 100)
arranged by size =  (frView 3-0 = 1011) and (frScript 6-4 = 100)
snap to grid =      (frView 3-0 = 1110) and (frScript 6-4 = 100)
========================================
List view:

frView 2-0 = 111
frFlags 9-5 = 10001
frOpenChain 31-30 = 11
frScript 6 = 1

no relative dates = (frFlags 4 = 1)
not collapsed =     (frFlags 5 = 1)
calc sizes =        (frFlags 8-6 = 111) and (frOpenChain 29 = 1) and (frScript 3 = 0)

normal icons =      (frScript 2-1 = 00)
large icons =       (frScript 2-1 = 10)
small icons =       (frScript 2-1 = 01)

has comments =      (frOpenChain 28 = 1)
has crDat =         (frOpenChain 23 = 1)
has kind =          (frOpenChain 25 = 1)
has label =         (frOpenChain 26 = 1)
has mdDat =         (frOpenChain 22 = 1)
has size =          (frOpenChain 24 = 1)
has version =       (frOpenChain 27 = 1)

select comments =   (frView 11-8 = 0110) and (frOpenChain 21-18 = 0110)
select crDat =      (frView 11-8 = 0010) and (frOpenChain 21-18 = 1001)
select kind =       (frView 11-8 = 0101) and (frOpenChain 21-18 = 0011)
select label =      (frView 11-8 = 0111)
select mdDat =      (frView 11-8 = 0011) and (frOpenChain 21-18 = 0001)
select name =       (frView 11-8 = 0010)
select size =       (frView 11-8 = 0100) and (frOpenChain 21-18 = 0010)
select version =    (frView 11-8 = 1000) and (frOpenChain 21-18 = 0101)
========================================

Part 2: 'colm' resource.

First:
'colm' 0x000A00010000000000000000

Then for every column:
- 4 character code:
    'pnam' = name,
    'asmo' = modification date,
    'ascd' = creation date,
    'phys' = size,
    'asty' = type,
    'fcrt' = creator,
    'kind' = kind,
    'labi' = label,
    'comt' = comment,
    'ver2' = version.
- 6 shorts:
    1. W6 (width - 6),
    2. 0,
    3. 0,
    4. 0 = standard, 1 = custom,
    5. 0,
    6. 0.

The column data is saved in the same order as the columns.
Name is always the first column.
If you move a column, then it's saved after the previous column.

Type and creator can be displayed by setting short nr 4 to 1.

Standard W6:
    name =              0xD0 =  208
    modification date = 0xA8 =  168
    creation date =     0xA8 =  168
    size =              0x3C =   60
    type =              0x36 =   54
    creator =           0x36 =   54
    kind =              0xA0 =  160
    label =             0x36 =   54
    comment =           0x118 = 280
    version =           0x3C =   60

Preferred window zoom height = 42 + 19 * item count.

Add 24 * (depth - 1) to the name column width.
Depth = depth of the tree of this folder if you remove the folders with no visible items.
Preferred window zoom width should be = total column width + 17.
but Finder adds 24 * (depth - 1) here too.
In other words: there's a bug in Finder.

Then I have to find how popup-windows and open window list are stored.
Title: Re: Designing a new Finder
Post by: IIO on December 26, 2021, 11:12:33 AM
I won't do the full path. A path in a menu is better.

a path in a menu is what already exists in OS9 finder. (?)
Title: Re: Designing a new Finder
Post by: Bolkonskij on December 27, 2021, 09:01:06 AM
Maybe a button that will help arrange the folders when in icon view?
Title: Re: Designing a new Finder
Post by: Cashed on January 22, 2022, 12:59:21 PM
Extending the functionality of Mac OS 9.3, and Beyond ! Post

Found this Japanese Mac OS 9 Fan.
There's some very intriguing descriptions of system enhancements, related to this subject -hence sharing the link (http://macos9.web.fc2.com/freeware/index.html).
Take a peek, especially in the: File operation / Function expansion / Disk / Folder database

Editing post to include the copy paste, for easy access:
File operations

super-duper-211.hqx Software that can copy all types of discs. Also supports Disk Copy and Shrink Wrap
FileBuddy 6.0.6J
Delivery-kun 117_ppc.lzh Create a set and automatically identify / type creator / move files, etc.
Substitute 1.7.6 FAT.sit High-performance multipurpose utility
rename

GoodRenamer_1.4JClassic.sit.bin
ABF Rename 3.4
drop-rename-35.hqx
numberinman13jp.sit.hqx
Backup / Sync

Tri-BACKUP 402 Easy to use
KzBackUpTool_v1.9.sit.bin Backs up the set folder at high speed by differential copy.
File / folder comparison
Count the contents of the diffy-doolittle-112.bin folder and compare each resource / data fork of the file with the same name to report
McCompare.sit.bin Find the difference between the data forks of the two files
SwitchBack-2.7.2J.sit Synchronize two folders and replace the latest files
Synchronize! 3.7 (SEA) Synchronize / backup two folders
updatecopy.sit.bin
Double file scan
Doublet Scan 4.0.5 Duplicate file scan
FindBySize.sit
Comment related

Archive Commenter 1.1 Write a comment to a compressed file Not a read / finder
Commentator Shareware Pacno.sit Finder Export comment?
CommentEditor1.0.sit.bin goCommentEditor non-RB version
goCommentEditor1.1.sit Edit comment in list view / Real basic version
super-comments-208.sit Managed from control panel?
UltraComment2.5 (PPC) .sit Write comments in bulk from a text file
search

findtext-136.hqx
You can also search inside Grapple_1.3.sit data / resources
powerscan-212.hqx
UltraFind22.hqx Powerful file search and information management utility that considers Macs and networks as searchable databases
CatFindFat.sea.bin Fast folder search
mojikensaku064.sit.bin Simple and fast, you can search up to 400 at a time, but if you press the button, the continuation will start Search in the folder
PowerCorpus3.ppc.sit.bin Search in folders that is not fast but has excellent formatting features for editing search results
Character search 0.2.0.lzh.bin Search in folder

Function expansion
Desktop enhancements

Virtual.2.0b2J.sit.bin Software that creates virtual desktops, such as x-window.
virtual-desktop-195.hqx A utility that adds scrollbars to your desktop to make your desktop pseudo-wider than the size of your display.
glidel_502_us.sit.hqx will be able to be added by dragging to the Apple menu
honeycombgrid.sit.hqx
Metericon_v0.9.sit.bin Paste disk space to icon
NaturalOrder.cpt.hqx 1 → 10 → 2 Sort
TileCity.sit This control panel adds a Tile menu to the Finder, allowing you to view different tiles and align windows.
TitlePop.sit Extension to make the window title a pop-up menu
tucows_filehand.hqx Extension to see information
WhatVersion.sit.bin Add version to file name
Decor304.sit Easily change your desktop picture
Multi-function launcher

ACTION GoMac 2.1.1 Add a Windows-like menu that moves in and out of the screen
AliasMenu 2.2.hqx Add an alias menu to the menu bar
HandyMan 2.0.5.sit Add alias to control bar
AreaLauncher.sit.hqx Launch the registered application by moving the cursor to the edge of the desktop
csmmakerppc.sit Software that creates the control bar module just by dropping the target application.
Drop Drawers 1.6.5 Installer Multimedia Launcher
LaunchBar1.3.2.sit Windowz-like toolbar. Switching open windows
mimi205lt.hqx A convenient drawer is attached to your desktop. Note paper, launcher, calendar, database
TaskMBar.sit
Appearance change

ChurchWindows1.2Installer.hqx
erikswindowdef.sit.hqx
Kaleidoscope 2.3.1 installer
niji-121.hqx
Genuine appearance

Theme Machine 0.4d1.sit processing
PreviewMaker_2.4.1_PPC.sit Appearance preview
S'Preview_1.3.sit.hqx Appearance Preview
Window_Builder1.1.sit.hqx Appearance Preview
Calendar / clock

himekuri.sit A ​​daily calendar that allows you to specify images
World_Clock_CSM_2.7_J.sit Control bar item that displays the time in the current world
World_Clock_Deluxe_3.1.2_J.sit World Clock
Daily turn 1.59.sit Show a lot of information about today
Overcoming _165.sit.hqx Control Bar Calendar

Disk / Folder database
disk disk

 Create a catalog with List_Files text
CDFinder  label print / folder creation / comment / MP3 tag reading
Database that creates an alias in the AutoCat2.2.sit folder
catalog2.1v2j.sit.hqx Folder X / 3 Hierarchical display in 3 windows
catfinder-215.hqx too simple
DiskCatalogMakerJ-4.0.smi
DiskFolder25P.sit
DiskRecall1.1.sit Folder cannot be created
DiskTracker 2.3.1.sit.bin Folder cannot be created / Comment
Tri-CATALOG_5US.sit Hierarchy in multiple windows / Enhanced image function / mp3 tag / Comment
Media management kit. img Control panel type catalog software + floppy label creation software + backup software
listup121.hqx Export the file information in the selected folder / disk as tabbed text (SimpleText document)
It is displayed like a mini-FileView0.5.sit tab / Drag a folder etc. to display it
NameClip1.0 (jp) .hqx Put the list of dragged and dropped files in the clipboard as text.
data

4D
ambry-134.sit for business use
Browsing file hierarchy browser type

FileObserver4.sit
gregsbrowser2.54fat.sit.hqx You can see the contents of the folder hierarchy in a fast and easy way by displaying multiple folders in one window.
interdisk1.1.sit
Prowler 2.0 to .sit Unique screen
ptah-1.0.1.sit.bin
Utility Doge 1.0
User information, etc.

eagledata.sit You can edit the layout, but the behavior is mellow
Memoranda_1.13_PPC.sit.hqx Layout editing / categorization
passwordmaster1.0.sit.bin Pass required at startup / Item name and path only
PasswordWallet_2.0.1_MacJ.sit Simple list display / encrypted storage of user name and password
SoftwareStation1.1.sit.hqx For soft data / list display
VSE My Privacy 1.1.hqx Category Filter / Folder Outline Editor Format / Cryptographically strong
Account BAN1.0_PPC.sit.bin Startup path / You can select items such as email, FTP, and text format.
Title: Re: Designing a new Finder
Post by: Cashed on January 28, 2022, 05:11:45 PM
Found this massive collection, dating all the way back to 1999. ATPM (http://www.atpm.com/5.10/roundup.shtml)
Oh I see there's 6 search results already, but last was from 2017, so it's a repost ;)
Some may know it, others may not. If you find something you want, but can't find, post it in the Requests (http://macos9lives.com/smforum/index.php/topic,6183.msg46306/topicseen.html#msg46306)
OS923 had his latest request after an hour, pm me it you want the v8 or v9 as well.
Plan to make a thread where all can post their links to sites they know of, it just makes it easier for newcomers. That collection thread can always be moved to new projects, in the future.

I'm in a cheese bell here, forgot to point out that I'd really like something done with the Extensions folder. Using EXTENSION OVERLOAD or better, found on the left side in the link. I find this the worst folder to view in Finder.

I can reach out to Daniel Chvatik if there's interests.
Title: Re: Designing a new Finder
Post by: OS923 on February 09, 2022, 08:40:11 AM
For me it's most practical if you have concrete ideas like:
- shift-drag like in Windows.
- Overwrite a file but keep the comment.
Title: Re: Designing a new Finder
Post by: IIO on February 11, 2022, 03:33:52 AM
Found this Japanese Mac OS 9 Fan.

if you are into this kind of stuff i have compiled a few here for you.

https://www.macintoshrepository.org/8223-system-extending-macos9plus-v1-0-extensions-and-control-panels-compilation-

it is all drag-install (i almost said "symlink" :D) and applied custom icons to, so that you can see the type (control panel or pseudo controlpanel application, extensions strip module, extension, contextmenu item) at one glance.

AWOL and a few others are still missing because it will be better to leave them in their original installer form.
 
 
Quote
I find this the worst folder to view in Finder.

it is for sure a mess as soon as you begin to install various extensions, libraries and hardware drivers.

what i do is this: after OS install, everything from the OS is getting a blue label color. the other 5 label colors are used for grouping things (choose whatever system you think is useful).



later when you need to find conflicting things or want to deinstall apps, go to list view, sort by label, the unlabelled ones on the bottom are the new ones. easy.