Mac OS 9 Lives! (Classic Mac OS Forum)

Classic Mac OS Software (Discussions on Applications) => 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 <mamo@sonosoft.com>
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)