Author Topic: Designing a new Finder  (Read 39636 times)

Offline nanopico

  • Moderator
  • Platinum Member (500+ Posts)
  • *****
  • Posts: 750
  • Liked:
  • Likes Given: 4
Re: Designing a new Finder
« Reply #75 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.
If it ain't broke, don't fix it, or break it so you can fix it!

Offline IIO

  • Platinum Member (500+ Posts)
  • *****
  • Posts: 3435
  • just a number
  • Liked:
  • Likes Given: 131
Re: Designing a new Finder
« Reply #76 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.
insert arbitrary signature here

Offline IIO

  • Platinum Member (500+ Posts)
  • *****
  • Posts: 3435
  • just a number
  • Liked:
  • Likes Given: 131
Re: Designing a new Finder
« Reply #77 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.
insert arbitrary signature here

Offline IIO

  • Platinum Member (500+ Posts)
  • *****
  • Posts: 3435
  • just a number
  • Liked:
  • Likes Given: 131
Re: Designing a new Finder
« Reply #78 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)
insert arbitrary signature here

Offline DieHard

  • Administrator
  • Platinum Member (500+ Posts)
  • *****
  • Posts: 1892
  • Liked:
  • Likes Given: 14
Re: Designing a new Finder
« Reply #79 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.

Offline OS923

  • Platinum Member (500+ Posts)
  • *****
  • Posts: 754
  • Liked:
  • Likes Given: 4
Re: Designing a new Finder
« Reply #80 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.
« Last Edit: May 03, 2017, 07:04:48 AM by OS923 »

Offline OS923

  • Platinum Member (500+ Posts)
  • *****
  • Posts: 754
  • Liked:
  • Likes Given: 4
Re: Designing a new Finder
« Reply #81 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.

Offline OS923

  • Platinum Member (500+ Posts)
  • *****
  • Posts: 754
  • Liked:
  • Likes Given: 4
Re: Designing a new Finder
« Reply #82 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.

Offline OS923

  • Platinum Member (500+ Posts)
  • *****
  • Posts: 754
  • Liked:
  • Likes Given: 4
Re: Designing a new Finder
« Reply #83 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.

Offline DieHard

  • Administrator
  • Platinum Member (500+ Posts)
  • *****
  • Posts: 1892
  • Liked:
  • Likes Given: 14
Re: Designing a new Finder
« Reply #84 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 :)

Offline WolfpackN64

  • Valued Member (10+ Posts)
  • **
  • Posts: 18
  • new to the forums
  • Liked:
  • Likes Given: 0
Re: Designing a new Finder
« Reply #85 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?

Offline OS923

  • Platinum Member (500+ Posts)
  • *****
  • Posts: 754
  • Liked:
  • Likes Given: 4
Re: Designing a new Finder
« Reply #86 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.

Offline WolfpackN64

  • Valued Member (10+ Posts)
  • **
  • Posts: 18
  • new to the forums
  • Liked:
  • Likes Given: 0
Re: Designing a new Finder
« Reply #87 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.

Offline OS923

  • Platinum Member (500+ Posts)
  • *****
  • Posts: 754
  • Liked:
  • Likes Given: 4
Re: Designing a new Finder
« Reply #88 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.

Offline OS923

  • Platinum Member (500+ Posts)
  • *****
  • Posts: 754
  • Liked:
  • Likes Given: 4
Re: Designing a new Finder
« Reply #89 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).

Offline classicmacreborn7

  • Valued Member (10+ Posts)
  • **
  • Posts: 17
  • New Member
  • Liked:
  • Likes Given: 0
Re: Designing a new Finder
« Reply #90 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...
« Last Edit: January 06, 2019, 08:49:02 PM by classicmacreborn7 »

Offline OS923

  • Platinum Member (500+ Posts)
  • *****
  • Posts: 754
  • Liked:
  • Likes Given: 4
Re: Designing a new Finder
« Reply #91 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.

Offline OS923

  • Platinum Member (500+ Posts)
  • *****
  • Posts: 754
  • Liked:
  • Likes Given: 4
Re: Designing a new Finder
« Reply #92 on: March 21, 2019, 06:52:47 AM »
This discussion is finished. Go to 9.3

Offline snes1423

  • Enthusiast Member (25+ Posts)
  • ***
  • Posts: 25
  • New Member
  • Liked:
  • Likes Given: 2
Re: Designing a new Finder
« Reply #93 on: December 10, 2020, 01:53:22 PM »
Hey os923 your websites down and clicking the link leads to Chinese malware  :(

Offline OS923

  • Platinum Member (500+ Posts)
  • *****
  • Posts: 754
  • Liked:
  • Likes Given: 4
Re: Designing a new Finder
« Reply #94 on: December 12, 2020, 03:43:47 AM »
My website had so many files and folders that it was difficult to maintain with FTP.

Offline OS923

  • Platinum Member (500+ Posts)
  • *****
  • Posts: 754
  • Liked:
  • Likes Given: 4
Re: Designing a new Finder
« Reply #95 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.

Offline teroyk

  • Gold Member (200+ Posts)
  • *****
  • Posts: 369
  • -
  • Liked:
  • Likes Given: 37
Re: Designing a new Finder
« Reply #96 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?
I bought my first new Mac when OS X 10.1 released. And I bought that Mac because it had Mac OS 9 too. And I bought my first 68k Mac when Apple stopped PPC Macs.

Offline cc333

  • Valued Member (10+ Posts)
  • **
  • Posts: 23
  • Liked:
  • Likes Given: 1
Re: Designing a new Finder
« Reply #97 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

Offline OS923

  • Platinum Member (500+ Posts)
  • *****
  • Posts: 754
  • Liked:
  • Likes Given: 4
Re: Designing a new Finder
« Reply #98 on: December 15, 2020, 01:08:18 PM »
Hack Finder?

Offline Hopfenholz

  • Enthusiast Member (25+ Posts)
  • ***
  • Posts: 37
  • New Member
  • Liked:
  • Likes Given: 3
Re: Designing a new Finder
« Reply #99 on: December 16, 2020, 12:55:31 AM »
I thought of a good name

9der

Offline OS923

  • Platinum Member (500+ Posts)
  • *****
  • Posts: 754
  • Liked:
  • Likes Given: 4
Re: Designing a new Finder
« Reply #100 on: December 23, 2020, 04:34:59 AM »
I know a bit more. It requires the Display Manager.

Offline OS923

  • Platinum Member (500+ Posts)
  • *****
  • Posts: 754
  • Liked:
  • Likes Given: 4
Re: Designing a new Finder
« Reply #101 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++.

Offline IIO

  • Platinum Member (500+ Posts)
  • *****
  • Posts: 3435
  • just a number
  • Liked:
  • Likes Given: 131
Re: Designing a new Finder
« Reply #102 on: December 25, 2020, 03:19:08 AM »
or Finder II
insert arbitrary signature here

Offline OS923

  • Platinum Member (500+ Posts)
  • *****
  • Posts: 754
  • Liked:
  • Likes Given: 4
Re: Designing a new Finder
« Reply #103 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.

Offline OS923

  • Platinum Member (500+ Posts)
  • *****
  • Posts: 754
  • Liked:
  • Likes Given: 4
Re: Designing a new Finder
« Reply #104 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

Offline IIO

  • Platinum Member (500+ Posts)
  • *****
  • Posts: 3435
  • just a number
  • Liked:
  • Likes Given: 131
Re: Designing a new Finder
« Reply #105 on: December 27, 2020, 09:05:19 AM »
image line is from belgium. but there it stops. :)
insert arbitrary signature here

Offline OS923

  • Platinum Member (500+ Posts)
  • *****
  • Posts: 754
  • Liked:
  • Likes Given: 4
Re: Designing a new Finder
« Reply #106 on: December 29, 2020, 06:06:17 AM »
That's not my idea of noteworthy.

Offline IIO

  • Platinum Member (500+ Posts)
  • *****
  • Posts: 3435
  • just a number
  • Liked:
  • Likes Given: 131
Re: Designing a new Finder
« Reply #107 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. :)
insert arbitrary signature here

Offline OS923

  • Platinum Member (500+ Posts)
  • *****
  • Posts: 754
  • Liked:
  • Likes Given: 4
Re: Designing a new Finder
« Reply #108 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.

Offline IIO

  • Platinum Member (500+ Posts)
  • *****
  • Posts: 3435
  • just a number
  • Liked:
  • Likes Given: 131
Re: Designing a new Finder
« Reply #109 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/
« Last Edit: December 31, 2020, 11:03:14 AM by IIO »
insert arbitrary signature here

Offline IIO

  • Platinum Member (500+ Posts)
  • *****
  • Posts: 3435
  • just a number
  • Liked:
  • Likes Given: 131
Re: Designing a new Finder
« Reply #110 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. :)
insert arbitrary signature here

Offline OS923

  • Platinum Member (500+ Posts)
  • *****
  • Posts: 754
  • Liked:
  • Likes Given: 4
Re: Designing a new Finder
« Reply #111 on: January 01, 2021, 05:05:25 AM »
... located in Belgium because Belgians want to meddle in everything.

Offline IIO

  • Platinum Member (500+ Posts)
  • *****
  • Posts: 3435
  • just a number
  • Liked:
  • Likes Given: 131
Re: Designing a new Finder
« Reply #112 on: January 01, 2021, 08:44:54 AM »
dont cry. you still have caramel wafers and newbeat. both is much appreciated.
insert arbitrary signature here

Offline OS923

  • Platinum Member (500+ Posts)
  • *****
  • Posts: 754
  • Liked:
  • Likes Given: 4
Re: Designing a new Finder
« Reply #113 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.

Offline IIO

  • Platinum Member (500+ Posts)
  • *****
  • Posts: 3435
  • just a number
  • Liked:
  • Likes Given: 131
Re: Designing a new Finder
« Reply #114 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.
insert arbitrary signature here

Offline OS923

  • Platinum Member (500+ Posts)
  • *****
  • Posts: 754
  • Liked:
  • Likes Given: 4
Re: Designing a new Finder
« Reply #115 on: January 08, 2021, 01:53:39 PM »
I mean the gray window frames.

Offline OS923

  • Platinum Member (500+ Posts)
  • *****
  • Posts: 754
  • Liked:
  • Likes Given: 4
Re: Designing a new Finder
« Reply #116 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.

Offline IIO

  • Platinum Member (500+ Posts)
  • *****
  • Posts: 3435
  • just a number
  • Liked:
  • Likes Given: 131
Re: Designing a new Finder
« Reply #117 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.
insert arbitrary signature here

Offline OS923

  • Platinum Member (500+ Posts)
  • *****
  • Posts: 754
  • Liked:
  • Likes Given: 4
Re: Designing a new Finder
« Reply #118 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.

Offline OS923

  • Platinum Member (500+ Posts)
  • *****
  • Posts: 754
  • Liked:
  • Likes Given: 4
Re: Designing a new Finder
« Reply #119 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?

Offline OS923

  • Platinum Member (500+ Posts)
  • *****
  • Posts: 754
  • Liked:
  • Likes Given: 4
Re: Designing a new Finder
« Reply #120 on: January 21, 2021, 07:27:06 AM »
I found it. Problem solved.

Offline IIO

  • Platinum Member (500+ Posts)
  • *****
  • Posts: 3435
  • just a number
  • Liked:
  • Likes Given: 131
Re: Designing a new Finder
« Reply #121 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.
insert arbitrary signature here

Offline IIO

  • Platinum Member (500+ Posts)
  • *****
  • Posts: 3435
  • just a number
  • Liked:
  • Likes Given: 131
Re: Designing a new Finder
« Reply #122 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.
insert arbitrary signature here

Offline IIO

  • Platinum Member (500+ Posts)
  • *****
  • Posts: 3435
  • just a number
  • Liked:
  • Likes Given: 131
Re: Designing a new Finder
« Reply #123 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?
insert arbitrary signature here

Offline OS923

  • Platinum Member (500+ Posts)
  • *****
  • Posts: 754
  • Liked:
  • Likes Given: 4
Re: Designing a new Finder
« Reply #124 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.

Offline gsteemso

  • Member
  • Posts: 4
  • Liked:
  • Likes Given: 0
Re: Designing a new Finder
« Reply #125 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.

Offline IIO

  • Platinum Member (500+ Posts)
  • *****
  • Posts: 3435
  • just a number
  • Liked:
  • Likes Given: 131
Re: Designing a new Finder
« Reply #126 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. :)

insert arbitrary signature here

Offline OS923

  • Platinum Member (500+ Posts)
  • *****
  • Posts: 754
  • Liked:
  • Likes Given: 4
Re: Designing a new Finder
« Reply #127 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.

Offline Mat

  • Platinum Member (500+ Posts)
  • *****
  • Posts: 592
  • Liked:
  • Likes Given: 0
Re: Designing a new Finder
« Reply #128 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.

Offline IIO

  • Platinum Member (500+ Posts)
  • *****
  • Posts: 3435
  • just a number
  • Liked:
  • Likes Given: 131
Re: Designing a new Finder
« Reply #129 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. :)
insert arbitrary signature here

Offline Mat

  • Platinum Member (500+ Posts)
  • *****
  • Posts: 592
  • Liked:
  • Likes Given: 0
Re: Designing a new Finder
« Reply #130 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.

Offline IIO

  • Platinum Member (500+ Posts)
  • *****
  • Posts: 3435
  • just a number
  • Liked:
  • Likes Given: 131
Re: Designing a new Finder
« Reply #131 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.
« Last Edit: May 31, 2021, 04:23:24 PM by IIO »
insert arbitrary signature here

Offline OS923

  • Platinum Member (500+ Posts)
  • *****
  • Posts: 754
  • Liked:
  • Likes Given: 4
Re: Designing a new Finder
« Reply #132 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.

Offline IIO

  • Platinum Member (500+ Posts)
  • *****
  • Posts: 3435
  • just a number
  • Liked:
  • Likes Given: 131
Re: Designing a new Finder
« Reply #133 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.

insert arbitrary signature here

Offline OS923

  • Platinum Member (500+ Posts)
  • *****
  • Posts: 754
  • Liked:
  • Likes Given: 4
Re: Designing a new Finder
« Reply #134 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.

Offline OS923

  • Platinum Member (500+ Posts)
  • *****
  • Posts: 754
  • Liked:
  • Likes Given: 4
Re: Designing a new Finder
« Reply #135 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.

Offline OS923

  • Platinum Member (500+ Posts)
  • *****
  • Posts: 754
  • Liked:
  • Likes Given: 4
Re: Designing a new Finder
« Reply #136 on: July 13, 2021, 07:23:08 AM »
 UnicodeNameEditor is discontinued because I donít use PowerPlant anymore.

Offline OS923

  • Platinum Member (500+ Posts)
  • *****
  • Posts: 754
  • Liked:
  • Likes Given: 4
Re: Designing a new Finder
« Reply #137 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.

Offline OS923

  • Platinum Member (500+ Posts)
  • *****
  • Posts: 754
  • Liked:
  • Likes Given: 4
Re: Designing a new Finder
« Reply #138 on: August 23, 2021, 08:33:11 AM »
I found the solution for the Unicode window titles.

Offline OS923

  • Platinum Member (500+ Posts)
  • *****
  • Posts: 754
  • Liked:
  • Likes Given: 4
Re: Designing a new Finder
« Reply #139 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.

Offline IIO

  • Platinum Member (500+ Posts)
  • *****
  • Posts: 3435
  • just a number
  • Liked:
  • Likes Given: 131
Re: Designing a new Finder
« Reply #140 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.
insert arbitrary signature here

Offline OS923

  • Platinum Member (500+ Posts)
  • *****
  • Posts: 754
  • Liked:
  • Likes Given: 4
Re: Designing a new Finder
« Reply #141 on: September 06, 2021, 09:00:34 AM »
I found it. The color was stored in an unlocked handle.

 


SimplePortal 2.3.6 © 2008-2014, SimplePortal