ThinkC MacDock dev progress -- Like today's macOS Dock but for System 7

[MacOfAllTrades]

Hey, you made it on HN https://news.ycombinator.com/item?id=35787119

Thanks so much @eric for posting!!! I’d never have known!

 

[retr01]

I think it’d be best for MacDock to stay the minimalist route.

Agreed! After all, things didn't really fluff up until MacOS 7.6 and became really fluffed up with MacOS 8. MacOS 9 is great for G3 and G4 Macs.

I prefer System 7. A lot simpler and still can do 32-bit stuff. System 6 is great for the SE and older with 4 MB of RAM doing 24-bit stuff.

 

[MacOfAllTrades]

Released - version 1.1

Git repo:
https://github.com/retrospectmike/MacDock

Direct download of the .sit:
https://github.com/retrospectmike/MacDock/releases/download/1.1/MacDock_v1.1.sit

Release notes:

• v1.1 -- 5/8/2023
  • No longer keeps After Dark screensavers from triggering when idle
  • Reduced CPU utilization by being selective about when to redraw the Dock and its icons
  • Added "About MacDock..." dialog
  • Reduced RAM requirements to 64k

Also on the git repo I've opened up a variety of "Issues" to capture the various ideas flowing in conversation here -- feel free to open additional ones as you see fit. I can't promise I'll tend to each one but I'll certainly read them all!!

Also - it's touching that it has 150 stars on GitHub. A while back I made a simple little iPhone app and I'm pretty sure it didn't get this level of response! Go figure! '80s computers FTW!!!

 

[MacOfAllTrades]

Released - version 1.1

Git repo:
https://github.com/retrospectmike/MacDock

Direct download of the .sit:
https://github.com/retrospectmike/MacDock/releases/download/1.1/MacDock_v1.1.sit

Release notes:

• v1.1 -- 5/8/2023
  • No longer keeps After Dark screensavers from triggering when idle
  • Reduced CPU utilization by being selective about when to redraw the Dock and its icons
  • Added "About MacDock..." dialog
  • Reduced RAM requirements to 64k

Also on the git repo I've opened up a variety of "Issues" to capture the various ideas flowing in conversation here -- feel free to open additional ones as you see fit. I can't promise I'll tend to each one but I'll certainly read them all!!

Also - it's touching that it has 150 stars on GitHub. A while back I made a simple little iPhone app and I'm pretty sure it didn't get this level of response! Go figure! '80s computers FTW!!!

note I noticed a small redraw issue -- fixed it within the same release so all of the above links still work. Sorry about that to anyone who downloaded it in the first 20 minutes since it was released before it was updated. Links above are still the best ones. No change there.

 

[retr01]

Nice!

I have a question, why not have an option whether or not to hide other apps when selecting an app on the Dock?

 

[MacOfAllTrades]

Nice!

I have a question, why not have an option whether or not to hide other apps when selecting an app on the Dock?

View attachment 12181 View attachment 12183

Im looking into all those ideas that flowed here! I just needed to roll out an update sooner with what I released yesterday. In particular After Dark compatibility (this was a big deal for me personally as I worry about my old screens) and the About Box needed to work too. I was pleased with the Susan Kare - inspired art :-D

 

[MacOfAllTrades]

Im looking into all those ideas that flowed here! I just needed to roll out an update sooner with what I released yesterday. In particular After Dark compatibility (this was a big deal for me personally as I worry about my old screens) and the About Box needed to work too. I was pleased with the Susan Kare - inspired art :-D

Fyi for other tinkerers - what did it for me was improving the logic so that MacDock didnt redraw its contents indiscriminately on Null events.
So while it still checks all running processes every Null event, it now checks if there are any changes to the running app list and only redraws the contents if there was a change.
On a modern system I’d use a custom class containing data and member functions to represent the dock but to reduce the overhead (and i welcome opinions) I made a global checksum of sorts that holds the sum of all the processes’ PSNs. If this number matches the new calculation for this number then I assume there’s been a change in the processes and I should draw the updated contents again.
Conversely i have a flag I can pass the update function that forces it to redraw regardless (this is useful for a few cases like when part of the MacDock was occluded and now uncovered ie from dragging another window off of it — no running process changes but it must be redrawn).

although the above did the trick — and the pattern here is that a redraw of the contents makes After Dark hold off on running (probably resets its internal timer) — I wonder *how does a blinking text cursor in an app like SimpleText not block After Dark*? If anyone knows Id love to know too!

thx

 

[Crutch]

I doubt that drawing per se blocks After Dark. (It would be hard/cumbersome for them to implement that in any event.)

I suspect you are doing something else in your nullEvt processing it is noticing. Are you calling BeginUpdate? (TEIdle, which is what SimpleText is certainly using, does not generate an update event, it simply blinks the caret itself.)

Your checksum idea is what I would have done too, though (I mentioned above somewhere) I would recommend allowing some min interval to elapse between checks. To really let the CPU flow you ideally don’t normally call any traps on a nullEvt. Ensuring it’s been at least 20 ticks or so since the last time should feel fast enough for users.

 

[MacOfAllTrades]

I doubt that drawing per se blocks After Dark. (It would be hard/cumbersome for them to implement that in any event.)

I suspect you are doing something else in your nullEvt processing it is noticing. Are you calling BeginUpdate? (TEIdle, which is what SimpleText is certainly using, does not generate an update event, it simply blinks the caret itself.)

Your checksum idea is what I would have done too, though (I mentioned above somewhere) I would recommend allowing some min interval to elapse between checks. To really let the CPU flow you ideally don’t normally call any traps on a nullEvt. Ensuring it’s been at least 20 ticks or so since the last time should feel fast enough for users.

Only call BeginUpdate() and EndUpdate() in the in my update event handler so it's not triggered when the computer is idle.

I'll add the min. timer for updates also. It's high time.

And @retr01 I'll look into the option+click to hide other apps!

 

[MacOfAllTrades]

Haha @retr01 you won't believe this--- but option+clicking on an app in MacDock will hide the current running app.

This is exactly how the standard Mac OS system 7 app switcher behaves (e.g. if you're in SimpleText and you use the menubar's app switcher to select Finder, holding the option key when you release the mouse -- you will hide SimpleText and switch to Finder).

This behavior is inherited in MacDock -- my best guess is that the LaunchApplication(...) process toolbox function I call does this (looks for the option key).

So that's the good news -- that MacDock already behaves like the System 7 app switcher does with respect to holding modifier keys (i.e. the option key).

The bad news- is that there is no easy and obvious way to do something like hide all applications or otherwise change the behavior of that ..
I'd like to at least let you Cmd+Click on an app and have it show you the app's file location in the finder (as modern macOS does when you cmd+click on an app). I'm looking into whether an apple event sent to the finder is needed or if there's a more direct way..

 

[Crutch]

There is no easy way to hide any application (or all applications) with a standard toolbox call. You can do it by faking out the Layer Manager and a bunch of hackery, I think.

To get the Finder to show a file’s location you need to use an AppleEvent.

 

[MacOfAllTrades]

There is no easy way to hide any application (or all applications) with a standard toolbox call. You can do it by faking out the Layer Manager and a bunch of hackery, I think.

To get the Finder to show a file’s location you need to use an AppleEvent.

Thx for confirming the apple event part.
And yes - I saw / remembered your post from a while back mentioning the Layer Manager as an in to hack around this.. I couldn't find much on the layer manger -- is it covered at all in Inside Macintosh?

The other way I thought could be an option was if I manually triggered the app switcher menu. It's automatically injected into the app by the Menu Manager -- if I could find some internal functions for it I could maybe call it that-a-ways?

 

[retr01]

This behavior is inherited in MacDock -- my best guess is that the LaunchApplication(...) process toolbox function I call does this (looks for the option key).

So that's the good news -- that MacDock already behaves like the System 7 app switcher does with respect to holding modifier keys (i.e. the option key).

Nice.

The bad news- is that there is no easy and obvious way to do something like hide all applications or otherwise change the behavior of that ..

Yeah. That's where software magic comes in.

I'd like to at least let you Cmd+Click on an app and have it show you the app's file location in the finder (as modern macOS does when you cmd+click on an app). I'm looking into whether an apple event sent to the finder is needed or if there's a more direct way..

Yeah. I think I saw an INIT / CDEV that has a contextual menus add-on.

 

[Crutch]

Thx for confirming the apple event part.
And yes - I saw / remembered your post from a while back mentioning the Layer Manager as an in to hack around this.. I couldn't find much on the layer manger -- is it covered at all in Inside Macintosh?

The other way I thought could be an option was if I manually triggered the app switcher menu. It's automatically injected into the app by the Menu Manager -- if I could find some internal functions for it I could maybe call it that-a-ways?

No sadly, the Layer Manager isn’t covered anywhere to my knowledge. It’s in the ROM and OS and you can find the source code for it online but there is no documentation anywhere that I’ve seen, since it was intended to be a private part of the Mac OS. (Applications aren’t supposed to mess with other applications… and more to the point, I think, Apple intended to change the way layers were handled internally in hypothetical future releases.). I even worked at stint at Apple in the ‘90s (as an intern admittedly but still writing classic Mac OS code all day with a giant loose leaf of New Inside Macintosh on my desk) but only know about the Layer Manager because I learned about it from some friendly folks over at 68kmla in 2020.

Triggering the Application menu is an interesting idea. I believe it’s implemented inside MenuSelect, which your app of course is calling. You would have to trick MenuSelect into thinking that the user had selected something from that menu. (This would probably require a patch to MenuSelect.)

 

[retr01]

@MacOfAllTrades, this adds contextual menus in System 7. Below are screenshots in System 7. MacOS 8 and up have additional options.

PowerMenu​

TBH, PowerMenu is too much for normal use.

Could MacDock add simpler contextual menus like open, quit, keep in the dock, and remove from the dock?

 

[MacOfAllTrades]

Does anyone know how to find the AppleEvents registry for the Finder?
I'm trying to use AE's to tell the finder to reveal a file (ie bring open the folder containing a program).
From what I can tell, apple had those monthly developer resource magazines and they'd include a CD with "Apple Event Registry" for the registered programs and presumably the Finder was in there too -- but I can't find it..

Anyway - maybe that's not the best place to look -- but I'm looking for info indicating what apple events the finder will respond to so that I can tell it to do stuff

Edit: the best I found so far was "FinderRegistry.h" here. I'm surprised Think C 5.0 didn't come with its own version of this .h file and I'm surprised at the few Finder Events listed:

enum {
    kAECleanUp                    = 'fclu',
    kAEEject                    = 'ejct',
    kAEEmpty                    = 'empt',
    kAEErase                    = 'fera',
    kAEGestalt                    = 'gstl',
    kAEPutAway                    = 'ptwy',
    kAERebuildDesktopDB            = 'rddb',
    kAESnooze                    = 'snoz',                // Go to sleep
    kAEUpdate                    = 'fupd'
};

Is that really the only things you can command the Finder to do via Apple Events? Not even Open of launch or close a window or..? More likely I'm sucking at understanding apple events properly...

Appreciate the help!

 

[retr01]

Does anyone know how to find the AppleEvents registry for the Finder?
I'm trying to use AE's to tell the finder to reveal a file (ie bring open the folder containing a program).
From what I can tell, apple had those monthly developer resource magazines and they'd include a CD with apple event registries for the registered programs and presumably the Finder was in there too -- but I can't find it.

Anyway - maybe that's not the best place to look -- but I'm looking for info indicating what apple events the finder will respond to so that I can tell it to do stuff

The Apple Events Registry maps the Apple events to a corresponding English language command. Apple maintains that database. When did they start that database? I am not sure. I will look.

 

[MacOfAllTrades]

The Apple Events Registry maps the Apple events to a corresponding English language command. Apple maintains that database. When did they start that database? I am not sure. I will look.

Hmm -- from what you're saying, I'm not sure it would be useful. I'm looking for some reference that will allow me to build AppleEvents in C that the Finder would understand. Like so that I can build an apple event that tells the finder to open a folder or a reveal the location of an application whose path I get.

If that's what you mean - then yes excellent! On the other hand I see AEs are tightly connected with AppleScript scripting which uses a sort of English syntax (like tell application 'Finder' activate). If that's what you mean then that wouldn't be so helpful. I can see the AppleScript dictionary already by opening the Finder's dictionary using the script editor.

 

[retr01]

@MacOfAllTrades, this is what I found on this HTML version of the "AppleScript in a Nutshell" book by Bruce W. Perry (2001):

1.2 Apple Events​

​

The AppleScript software development kit (SDK) includes a FileMaker Pro file that contains the Apple Event Registry for AppleScript Version 1.3.4. Go to http://developer.apple.com/sdk for more SDK information.​

​

I am going to find it.

 

[retr01]

Hmm -- from what you're saying, I'm not sure it would be useful. I'm looking for some reference that will allow me to build AppleEvents in C that the Finder would understand. Like so that I can build an apple event that tells the finder to open a folder or a reveal the location of an application whose path I get.

If that's what you mean - then yes excellent! On the other hand I see AEs are tightly connected with AppleScript scripting which uses a sort of English syntax (like tell application 'Finder' activate). If that's what you mean then that wouldn't be so helpful. I can see the AppleScript dictionary already by opening the Finder's dictionary using the script editor.

AE commands work in C, Java, etc. Well, Apple's database is the whole set of AEs and tells you what that command does and how to implement it. I need to find it to see.